man(7) - Linux man page

Name

man - macros to format man pages

Synopsis

groff -Tascii -man file ...

groff -Tps -man file ...

man [section] title

Description

This manual page explains the groff tmac.an macro package (often called the man macro package) and related conventions for creating manual (man) pages. This macro package should be used by developers when writing or porting man pages for Linux. It is fairly compatible with other versions of this macro package, so porting man pages should not be a major problem (exceptions include the NET-2 BSD release, which uses a totally different macro package called mdoc; see mdoc(7)).

Note that NET-2 BSD mdoc man pages can be used with groff simply by specifying the -mdoc option instead of the -man option. Using the -mandoc option is, however, recommended, since this will automatically detect which macro package is in use.

Preamble

The first command in a man page (after comment lines) should be

.TH title section date source manual,

where:
title
The title of the man page (e.g., MAN).
section
The section number the man page should be placed in (e.g., 7).
date
The date of the last revision--remember to change this every time a change is made to the man page, since this is the most general way of doing version control.
source
The source of the command.

For binaries, use something like: GNU, NET-2, SLS Distribution, MCC Distribution.

For system calls, use the version of the kernel that you are currently looking at: Linux 0.99.11.

For library calls, use the source of the function: GNU, 4.3BSD, Linux DLL 4.4.1.

manual
The title of the manual (e.g., Linux Programmer's Manual).

Note that BSD mdoc-formatted pages begin with the Dd command, not the TH command.

The manual sections are traditionally defined as follows:

1 Commands
Those commands that can be executed by the user from within a shell.
2 System calls
Those functions which must be performed by the kernel.
3 Library calls
Most of the libc functions, such as qsort(3).
4 Special files
Files found in /dev.
5 File formats and conventions
The format for /etc/passwd and other human-readable files.
6 Games
7 Conventions and miscellaneous
A description of the standard file system layout, network protocols, ASCII and other character codes, this man page, and other things.
8 System management commands
Commands like mount(8), many of which only root can execute.
9 Kernel routines
This is an obsolete manual section. Once it was thought a good idea to document the Linux kernel here, but in fact very little has been documented, and the documentation that exists is outdated already. There are better sources of information for kernel developers.

Sections

Sections are started with .SH followed by the heading name. If the name contains spaces and appears on the same line as .SH, then place the heading in double quotes. Traditional or suggested headings include: NAME, SYNOPSIS, DESCRIPTION, RETURN VALUE, EXIT STATUS, ERROR HANDLING, ERRORS, OPTIONS, USAGE, EXAMPLES, FILES, ENVIRONMENT, DIAGNOSTICS, SECURITY, CONFORMING TO, NOTES, BUGS, AUTHOR, and SEE ALSO. Where a traditional heading would apply, please use it; this kind of consistency can make the information easier to understand. However, feel free to create your own headings if they make things easier to understand. The only required heading is NAME, which should be the first section and be followed on the next line by a one line description of the program:

.SH NAME
chess \- the game of chess

It is extremely important that this format is followed, and that there is a backslash before the single dash which follows the command name. This syntax is used by the makewhatis(8) program to create a database of short command descriptions for the whatis(1) and apropos(1) commands.

Some other traditional sections have the following contents:

SYNOPSIS
briefly describes the command or function's interface. For commands, this shows the syntax of the command and its arguments (including options); boldface is used for as-is text and italics are used to indicate replaceable arguments. Brackets ([]) surround optional arguments, vertical bars (|) separate choices, and ellipses (...) can be repeated. For functions, it shows any required data declarations or #include directives, followed by the function declaration.
DESCRIPTION
gives an explanation of what the command, function, or format does. Discuss how it interacts with files and standard input, and what it produces on standard output or standard error. Omit internals and implementation details unless they're critical for understanding the interface. Describe the usual case; for information on options use the OPTIONS section. If there is some kind of input grammar or complex set of subcommands, consider describing them in a separate USAGE section (and just place an overview in the DESCRIPTION section).
RETURN VALUE
gives a list of the values the library routine will return to the caller and the conditions that cause these values to be returned.
EXIT STATUS
lists the possible exit status values or a program and the conditions that cause these values to be returned.
OPTIONS
describes the options accepted by the program and how they change its behavior.
USAGE
describes the grammar of any sublanguage this implements.
EXAMPLES
provides one or more examples describing how this function, file or command is used.
FILES
lists the files the program or function uses, such as configuration files, startup files, and files the program directly operates on. Give the full pathname of these files, and use the installation process to modify the directory part to match user preferences. For many programs, the default installation location is in /usr/local, so your base manual page should use /usr/local as the base.
ENVIRONMENT
lists all environment variables that affect your program or function and how they affect it.
DIAGNOSTICS
gives an overview of the most common error messages and how to cope with them. You don't need to explain system error messages or fatal signals that can appear during execution of any program unless they're special in some way to your program.
SECURITY
discusses security issues and implications. Warn about configurations or environments that should be avoided, commands that may have security implications, and so on, especially if they aren't obvious. Discussing security in a separate section isn't necessary; if it's easier to understand, place security information in the other sections (such as the DESCRIPTION or USAGE section). However, please include security information somewhere!
CONFORMING TO
describes any standards or conventions this implements.
NOTES
provides miscellaneous notes.
BUGS
lists limitations, known defects or inconveniences, and other questionable activities.
AUTHOR
lists authors of the documentation or program so you can mail in bug reports.
SEE ALSO
lists related man pages in alphabetical order, possibly followed by other related pages or documents. Conventionally this is the last section.

Fonts

Although there are many arbitrary conventions for man pages in the UNIX world, the existence of several hundred Linux-specific man pages defines our font standards:
For functions, the arguments are always specified using italics,
even in the SYNOPSIS section, where the rest of the function is specified in bold:
int myfunction(int argc, char **argv);
Filenames are always in italics (e.g.,
/usr/include/stdio.h), except in the SYNOPSIS section, where included files are in bold (e.g., #include <stdio.h>).
Special macros, which are usually in upper case, are in bold (e.g.,
MAXINT).
When enumerating a list of error codes, the codes are in bold (this list
usually uses the .TP macro).
Any reference to another man page (or to the subject of the current man
page) is in bold. If the manual section number is given, it is given in Roman (normal) font, without any spaces (e.g., man(7)).

The commands to select the type face are:

Traditionally, each command can have up to six arguments, but the GNU implementation removes this limitation (you might still want to limit yourself to 6 arguments for portability's sake). Arguments are delimited by spaces. Double quotes can be used to specify an argument which contains spaces. All of the arguments will be printed next to each other without intervening spaces, so that the .BR command can be used to specify a word in bold followed by a mark of punctuation in Roman. If no arguments are given, the command is applied to the following line of text.

Other Macros and Strings

Below are other relevant macros and predefined strings. Unless noted otherwise, all macros cause a break (end the current line of text). Many of these macros set or use the "prevailing indent." The "prevailing indent" value is set by any macro with the parameter i below; macros may omit i in which case the current prevailing indent will be used. As a result, successive indented paragraphs can use the same indent without re-specifying the indent value. A normal (non-indented) paragraph resets the prevailing indent value to its default value (0.5 inches). By default a given indent is measured in ens; try to use ens or ems as units for indents, since these will automatically adjust to font size changes. The other key macro definitions are:

Normal Paragraphs

Relative Margin Indent

Indented Paragraph Macros

Hypertext Link Macros

(Feature supported with groff only.) In order to use hypertext link macros, it is necessary to load the www.tmac macro package. Use the request .mso www.tmac to do this.