Preamble

The first command in a man page (after comment lines, that is, lines that start with .\") should be

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

The manual sections are traditionally defined as follows:

Sections

Sections are started with .SH followed by the heading name. The list below shows conventional or suggested sections. Most manual pages should include at least the highlighted sections. Please try to arrange a new manual page so that sections are placed in approximately the order shown in the list.

NAME
SYNOPSIS
DESCRIPTION
OPTIONS            [Normally only in sections 1, 8]
ENVIRONMENT
FILES
VERSIONS           [Normally only in sections 2, 3]
RETURN VALUE       [Normally only in sections 2, 3]
EXIT STATUS        [Normally only in sections 1, 8]
ERRORS             [Typically only in sections 2, 3]
CONFORMING TO
NOTES
BUGS
EXAMPLE
SEE ALSO

Where a traditional heading would apply, please use it; this kind of consistency can make the information easier to understand. If you must, you can create your own headings if they make things easier to understand (this can be especially useful for pages in sections 4 and 5). However, before doing this, consider whether you could use the traditional headings, with some subsections (.SS) within those sections.

The only mandatory heading is NAME, which should be the first section and be followed on the next line by a one line description of the program:

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 program, 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 command-line options of a program use the OPTIONS 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 of a program and the conditions that cause these values to be returned. This section should only appear for Section 1 and 8 manual pages.

OPTIONS

describes the command-line options accepted by a program and how they change its behavior. This section should only appear for Section 1 and 8 manual pages.

EXAMPLE

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 the program or function and how they affect it.

VERSIONS

A brif summary of the Linux kernel or glibc versions where a system call or library function appeared, or changed significantly in its operation.

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. Use of an AUTHOR section is discouraged. (One exception is section 4 pages that list the authors of device drivers, to whom software bugs should be sent.) Generally, it is better not to clutter every page with a list of (over time potentially numerous) authors; if you write or significantly amend a page, add a copyright notice as a comment in the source file.

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:

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 the subject of the current manual page should be written with the name in bold, followed by a pair of parentheses in Roman (normal) font, e.g., man(). The preferred way to write this in the source file is:

    .BR man ()
    

(Using this format, rather than the use of "\fB...\fP()" makes it easier to write tools that parse man page source files.)

Any reference to another man page should be written with the name in bold, always followed by the section number, formatted in Roman (normal) font, without any separating spaces (e.g., intro(2)). The preferred way to write this in the source file is:

    .BR intro (2)
    

(Including the section number in cross references lets tools like man2html create properly hyperlinked pages.)

The commands to select the type face are:

.B

Bold

.BI

Bold alternating with italics (especially useful for function specifications)

.BR

Bold alternating with Roman (especially useful for referring to other manual pages)

.I

Italics

.IB

Italics alternating with bold

.IR

Italics alternating with Roman

.RB

Roman alternating with bold

.RI

Roman alternating with italics

.SB

Small alternating with bold

.SM

Small (useful for acronyms)

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

.LP

Same as .PP (begin a new paragraph).

.P

Same as .PP (begin a new paragraph).

.PP

Begin a new paragraph and reset prevailing indent.

Relative Margin Indent

.RS i

Start relative margin indent: moves the left margin i to the right (if i is omitted, the prevailing indent value is used). A new prevailing indent is set to 0.5 inches. As a result, all following paragraph(s) will be indented until the corresponding .RE.

.RE

End relative margin indent and restores the previous value of the prevailing indent.

Indented Paragraph Macros

.HP i

Begin paragraph with a hanging indent (the first line of the paragraph is at the left margin of normal paragraphs, and the rest of the paragraph's lines are indented).

.IP x i

Indented paragraph with optional hanging tag. If the tag x is omitted, the entire following paragraph is indented by i. If the tag x is provided, it is hung at the left margin before the following indented paragraph (this is just like .TP except the tag is included with the command instead of being on the following line). If the tag is too long, the text after the tag will be moved down to the next line (text will not be lost or garbled). For bulleted lists, use this macro with \(bu (bullet) or \(em (em dash) as the tag, and for numbered lists, use the number or letter followed by a period as the tag; this simplifies translation to other formats.

.TP i

Begin paragraph with hanging tag. The tag is given on the next line, but its results are like those of the .IP command.

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.

.URL url link trailer

Inserts a hypertext link to the URI (URL) url, with link as the text of the link. The trailer will be printed immediately afterwards. When generating HTML this should translate into the HTML command <A HREF="url">link</A>trailer.

This and other related macros are new, and many tools won't do anything with them, but since many tools (including troff) will simply ignore undefined macros (or at worst insert their text) these are safe to insert.

It can be useful to define your own URL macro in manual pages for the benefit of those viewing it with a roff viewer other than groff. That way, the URL, link text, and trailer text (if any) are still visible.

Here's an example:

In the above, if groff is being used, the www.tmac macro package's definition of the URL macro will supersede the locally defined one.

A number of other link macros are available. See groff_www(7) for more details.

Miscellaneous Macros

.DT

Reset tabs to default tab values (every 0.5 inches); does not cause a break.

.PD d

Set inter-paragraph vertical distance to d (if omitted, d=0.4v); does not cause a break.

.SS t

Subheading t (like .SH, but used for a subsection inside a section).

Predefined Strings

The man package has the following predefined strings:

\*R

Registration Symbol: ®

\*S

Change to default font size

\*(Tm

Trademark Symbol: (Tm)

\*(lq

Left angled doublequote: “

\*(rq

Right angled doublequote: ”

Safe Subset

Although technically man is a troff macro package, in reality a large number of other tools process man page files that don't implement all of troff's abilities. Thus, it's best to avoid some of troff's more exotic abilities where possible to permit these other tools to work correctly. Avoid using the various troff preprocessors (if you must, go ahead and use tbl(1), but try to use the IP and TP commands instead for two-column tables). Avoid using computations; most other tools can't process them. Use simple commands that are easy to translate to other formats. The following troff macros are believed to be safe (though in many cases they will be ignored by translators): \", ., ad, bp, br, ce, de, ds, el, ie, if, fi, ft, hy, ig, in, na, ne, nf, nh, ps, so, sp, ti, tr.

You may also use many troff escape sequences (those sequences beginning with \). When you need to include the backslash character as normal text, use \e. Other sequences you may use, where x or xx are any characters and N is any digit, include: \', \`, \-, \., \", \%, \*x, \*(xx, \(xx, \$N, \nx, \n(xx, \fx, and \f(xx. Avoid using the escape sequences for drawing graphics.

Do not use the optional parameter for bp (break page). Use only positive values for sp (vertical space). Don't define a macro (de) with the same name as a macro in this or the mdoc macro package with a different meaning; it's likely that such redefinitions will be ignored. Every positive indent (in) should be paired with a matching negative indent (although you should be using the RS and RE macros instead). The condition test (if,ie) should only have 't' or 'n' as the condition. Only translations (tr) that can be ignored should be used. Font changes (ft and the \f escape sequence) should only have the values 1, 2, 3, 4, R, I, B, P, or CW (the ft command may also have no parameters).

If you use capabilities beyond these, check the results carefully on several tools. Once you've confirmed that the additional capability is safe, let the maintainer of this document know about the safe command or sequence that should be added to this list.