MAN(7) OpenBSD Reference Manual MAN(7)NAMEman - man language reference
DESCRIPTION
The man language was historically used to format UNIX manuals. This
reference document describes its syntax, structure, and usage.
Do not use man to write your manuals. Use the mdoc(7) language, instead.
A man document follows simple rules: lines beginning with the control
character `.' are parsed for macros. Other lines are interpreted within
the scope of prior macros:
.SH Macro lines change control state.
Other lines are interpreted within the current state.
INPUT ENCODINGman documents may contain only graphable 7-bit ASCII characters, the
space character, and the tab character.
Blank lines are acceptable; where found, the output will assert a
vertical space.
If the first character of a line is a space, that line is printed with a
leading newline.
Comments
Text following a `\"', whether in a macro or free-form text line, is
ignored to the end of line. A macro line with only a control character
and comment escape, `.\"', is also ignored. Macro lines with only a
control character and optionally whitespace are stripped from input.
Special Characters
Special characters may occur in both macro and free-form lines.
Sequences begin with the escape character `\' followed by either an open-
parenthesis `(' for two-character sequences; an open-bracket `[' for n-
character sequences (terminated at a close-bracket `]'); or a single one-
character sequence. See mandoc_char(7) for a complete list. Examples
include `\(em' (em-dash) and `\e' (back-slash).
Text Decoration
Terms may be text-decorated using the `\f' escape followed by an
indicator: B (bold), I (italic), R (Roman), or P (revert to previous
mode):
\fBbold\fR \fIitalic\fP
A numerical representation 3, 2, or 1 (bold, italic, and Roman,
respectively) may be used instead. A text decoration is only valid, if
specified in free-form text, until the next macro invocation; if
specified within a macro, it's only valid until the macro closes scope.
Note that macros like BR open and close a font scope with each argument.
The `\f' attribute is forgotten when entering or exiting a macro block.
Whitespace
Whitespace consists of the space character. In free-form lines,
whitespace is preserved within a line; unescaped trailing spaces are
stripped from input (unless in a literal context). Blank free-form
lines, which may include spaces, are permitted and rendered as an empty
line.
In macro lines, whitespace delimits arguments and is discarded. If
arguments are quoted, whitespace within the quotes is retained.
Dates
The TH macro is the only man macro that requires a date. The form for
this date is the ISO-8601 standard YYYY-MM-DD.
Scaling Widths
Many macros support scaled widths for their arguments, such as
stipulating a two-inch paragraph indentation with the following:
.HP 2i
The syntax for scaled widths is `[+-]?[0-9]*.[0-9]*[:unit:]?', where a
decimal must be preceded or proceeded by at least one digit. Negative
numbers, while accepted, are truncated to zero. The following scaling
units are accepted:
c centimetre
i inch
P pica (~1/6 inch)
p point (~1/72 inch)
f synonym for `u'
v default vertical span
m width of rendered `m' (em) character
n width of rendered `n' (en) character
u default horizontal span
M mini-em (~1/100 em)
Using anything other than `m', `n', `u', or `v' is necessarily non-
portable across output media.
If a scaling unit is not provided, the numerical value is interpreted
under the default rules of `v' for vertical spaces and `u' for horizontal
ones. Note: this differs from mdoc(7), which, if a unit is not provided,
will instead interpret the string as literal text.
Sentence Spacing
When composing a manual, make sure that sentences end at the end of a
line. By doing so, front-ends will be able to apply the proper amount of
spacing after the end of sentence (unescaped) period, exclamation mark,
or question mark followed by zero or more non-sentence closing delimiters
(`)', `]', `'', `"').
MANUAL STRUCTURE
Each man document must contain the TH macro describing the document's
section and title. It may occur anywhere in the document, although
conventionally it appears as the first macro.
Beyond TH, at least one macro or text node must appear in the document.
Documents are generally structured as follows:
.TH FOO 1 2009-10-10
.SH NAME
\fBfoo\fR \(en a description goes here
.\" .SH LIBRARY
.\" For sections 2 & 3 only.
.\" Not used in OpenBSD.
.SH SYNOPSIS
\fBfoo\fR [\fB\-options\fR] arguments...
.SH DESCRIPTION
The \fBfoo\fR utility processes files...
.\" .SH IMPLEMENTATION NOTES
.\" Not used in OpenBSD.
.\" .SH RETURN VALUES
.\" For sections 2, 3, & 9 only.
.\" .SH ENVIRONMENT
.\" For sections 1, 6, 7, & 8 only.
.\" .SH FILES
.\" .SH EXIT STATUS
.\" For sections 1, 6, & 8 only.
.\" .SH EXAMPLES
.\" .SH DIAGNOSTICS
.\" For sections 1, 4, 6, 7, & 8 only.
.\" .SH ERRORS
.\" For sections 2, 3, & 9 only.
.\" .SH SEE ALSO
.\" .BR foo ( 1 )
.\" .SH STANDARDS
.\" .SH HISTORY
.\" .SH AUTHORS
.\" .SH CAVEATS
.\" .SH BUGS
.\" .SH SECURITY CONSIDERATIONS
.\" Not used in OpenBSD.
The sections in a man document are conventionally ordered as they appear
above. Sections should be composed as follows:
NAME
The name(s) and a short description of the documented material.
The syntax for this is generally as follows:
\fBname\fR \(en description
LIBRARY
The name of the library containing the documented material, which
is assumed to be a function in a section 2 or 3 manual. For
functions in the C library, this may be as follows:
Standard C Library (libc, -lc)
SYNOPSIS
Documents the utility invocation syntax, function call syntax, or
device configuration.
For the first, utilities (sections 1, 6, and 8), this is generally
structured as follows:
\fBname\fR [-\fBab\fR] [-\fBc\fR\fIarg\fR] \fBpath\fR...
For the second, function calls (sections 2, 3, 9):
.B char *name(char *\fIarg\fR);
And for the third, configurations (section 4):
.B name* at cardbus? function?
Manuals not in these sections generally don't need a SYNOPSIS.
DESCRIPTION
This expands upon the brief, one-line description in NAME. It
usually contains a break-down of the options (if documenting a
command).
IMPLEMENTATION NOTES
Implementation-specific notes should be kept here. This is useful
when implementing standard functions that may have side effects or
notable algorithmic implications.
RETURN VALUES
This section documents the return values of functions in sections
2, 3, and 9.
ENVIRONMENT
Documents any usages of environment variables, e.g., environ(7).
FILES
Documents files used. It's helpful to document both the file name
and a short description of how the file is used (created, modified,
etc.).
EXIT STATUS
This section documents the command exit status for section 1, 6,
and 8 utilities. Historically, this information was described in
DIAGNOSTICS, a practise that is now discouraged.
EXAMPLES
Example usages. This often contains snippets of well-formed, well-
tested invocations. Make sure that examples work properly!
DIAGNOSTICS
Documents error conditions. This is most useful in section 4
manuals. Historically, this section was used in place of EXIT
STATUS for manuals in sections 1, 6, and 8; however, this practise
is discouraged.
ERRORS
Documents error handling in sections 2, 3, and 9.
SEE ALSO
References other manuals with related topics. This section should
exist for most manuals.
.BR bar ( 1 ),
Cross-references should conventionally be ordered first by section,
then alphabetically.
STANDARDS
References any standards implemented or used, such as
IEEE Std 1003.2 (\(lqPOSIX.2\(rq)
If not adhering to any standards, the HISTORY section should be
used.
HISTORY
A brief history of the subject, including where support first
appeared.
AUTHORS
Credits to the person or persons who wrote the code and/or
documentation. Authors should generally be noted by both name and
email address.
CAVEATS
Common misuses and misunderstandings should be explained in this
section.
BUGS
Known bugs, limitations, and work-arounds should be described in
this section.
SECURITY CONSIDERATIONS
Documents any security precautions that operators should consider.
MACRO SYNTAX
Macros are one to three characters in length and begin with a control
character, `.', at the beginning of the line. The `'' macro control
character is also accepted. An arbitrary amount of whitespace (spaces or
tabs) may sit between the control character and the macro name. Thus,
the following are equivalent:
.PP
. PP
To include space characters in macro arguments, arguments may be quoted;
see the `MACRO SYNTAX' section in the roff(7) manual for details.
The man macros are classified by scope: line scope or block scope. Line
macros are only scoped to the current line (and, in some situations, the
subsequent line). Block macros are scoped to the current line and
subsequent lines until closed by another block macro.
Line Macros
Line macros are generally scoped to the current line, with the body
consisting of zero or more arguments. If a macro is scoped to the next
line and the line arguments are empty, the next line, which must be text,
is used instead. Thus:
.I
foo
is equivalent to `.I foo'. If next-line macros are invoked
consecutively, only the last is used. If a next-line macro is followed
by a non-next-line macro, an error is raised, except for br, sp, and na.
The syntax is as follows:
.YO [body...]
[body...]
Macro Arguments Scope Notes
AT <=1 current
B n next-line
BI n current
BR n current
DT 0 current
I n next-line
IB n current
IR n current
R n next-line
RB n current
RI n current
SB n next-line
SM n next-line
TH >1, <6 current
UC <=1 current
br 0 current compat
fi 0 current compat
in 1 current compat
na 0 current compat
nf 0 current compat
sp 1 current compat
Macros marked as "compat" are included for compatibility with the
significant corpus of existing manuals that mix dialects of roff. These
macros should not be used for portable man manuals.
Block Macros
Block macros comprise a head and body. As with in-line macros, the head
is scoped to the current line and, in one circumstance, the next line
(the next-line stipulations as in Line Macros apply here as well).
The syntax is as follows:
.YO [head...]
[head...]
[body...]
The closure of body scope may be to the section, where a macro is closed
by SH; sub-section, closed by a section or SS; part, closed by a section,
sub-section, or RE; or paragraph, closed by a section, sub-section, part,
HP, IP, LP, P, PP, or TP. No closure refers to an explicit block closing
macro.
As a rule, block macros may not be nested; thus, calling a block macro
while another block macro scope is open, and the open scope is not
implicitly closed, is syntactically incorrect.
Macro Arguments Head Scope Body Scope Notes
HP <2 current paragraph
IP <3 current paragraph
LP 0 current paragraph
P 0 current paragraph
PP 0 current paragraph
RE 0 current none compat
RS 1 current part compat
SH >0 next-line section
SS >0 next-line sub-section
TP n next-line paragraph
Macros marked "compat" are as mentioned in Line Macros.
If a block macro is next-line scoped, it may only be followed by in-line
macros for decorating text.
REFERENCE
This section is a canonical reference to all macros, arranged
alphabetically. For the scoping of individual macros, see MACRO SYNTAX.
AT
Sets the volume for the footer for compatibility with man pages from AT&T
UNIX releases. The optional arguments specify which release it is from.
B
Text is rendered in bold face.
See also I and R.
BI
Text is rendered alternately in bold face and italic. Thus, `.BI this
word and that' causes `this' and `and' to render in bold face, while
`word' and `that' render in italics. Whitespace between arguments is
omitted in output.
Examples:
.BI bold italic bold italic
The output of this example will be emboldened ``bold'' and italicised
``italic'', with spaces stripped between arguments.
See also IB, BR, RB, RI, and IR.
BR
Text is rendered alternately in bold face and roman (the default font).
Whitespace between arguments is omitted in output.
See BI for an equivalent example.
See also BI, IB, RB, RI, and IR.
DT
Has no effect. Included for compatibility.
HP
Begin a paragraph whose initial output line is left-justified, but
subsequent output lines are indented, with the following syntax:
.HP [width]
The width argument must conform to Scaling Widths. If specified, it's
saved for later paragraph left-margins; if unspecified, the saved or
default width is used.
See also IP, LP, P, PP, and TP.
I
Text is rendered in italics.
See also B and R.
IB
Text is rendered alternately in italics and bold face. Whitespace
between arguments is omitted in output.
See BI for an equivalent example.
See also BI, BR, RB, RI, and IR.
IP
Begin an indented paragraph with the following syntax:
.IP [head [width]]
The width argument defines the width of the left margin and is defined by
Scaling Widths. It's saved for later paragraph left-margins; if
unspecified, the saved or default width is used.
The head argument is used as a leading term, flushed to the left margin.
This is useful for bulleted paragraphs and so on.
See also HP, LP, P, PP, and TP.
IR
Text is rendered alternately in italics and roman (the default font).
Whitespace between arguments is omitted in output.
See BI for an equivalent example.
See also BI, IB, BR, RB, and RI.
LP
Begin an undecorated paragraph. The scope of a paragraph is closed by a
subsequent paragraph, sub-section, section, or end of file. The saved
paragraph left-margin width is reset to the default.
See also HP, IP, P, PP, and TP.
P
Synonym for LP.
See also HP, IP, LP, PP, and TP.
PP
Synonym for LP.
See also HP, IP, LP, P, and TP.
R
Text is rendered in roman (the default font).
See also I and B.
RB
Text is rendered alternately in roman (the default font) and bold face.
Whitespace between arguments is omitted in output.
See BI for an equivalent example.
See also BI, IB, BR, RI, and IR.
RE
Explicitly close out the scope of a prior RS.
RI
Text is rendered alternately in roman (the default font) and italics.
Whitespace between arguments is omitted in output.
See BI for an equivalent example.
See also BI, IB, BR, RB, and IR.
RS
Begin a part setting the left margin. The left margin controls the
offset, following an initial indentation, to un-indented text such as
that of PP. This has the following syntax:
.Rs [width]
The width argument must conform to Scaling Widths. If not specified, the
saved or default width is used.
SB
Text is rendered in small size (one point smaller than the default font)
bold face.
SH
Begin a section. The scope of a section is only closed by another
section or the end of file. The paragraph left-margin width is reset to
the default.
SM
Text is rendered in small size (one point smaller than the default font).
SS
Begin a sub-section. The scope of a sub-section is closed by a
subsequent sub-section, section, or end of file. The paragraph left-
margin width is reset to the default.
TH
Sets the title of the manual page with the following syntax:
.TH title section [date [source [volume]]]
At least the upper-case document title and the manual section arguments
must be provided. The date argument should be formatted as described in
Dates, but will be printed verbatim if it is not. If the date is not
specified, the current date is used. The source string specifies the
organisation providing the utility. The volume string replaces the
default rendered volume, which is dictated by the manual section.
Examples:
.TH CVS 5 1992-02-12 GNU
TP
Begin a paragraph where the head, if exceeding the indentation width, is
followed by a newline; if not, the body follows on the same line after a
buffer to the indentation width. Subsequent output lines are indented.
The syntax is as follows:
.TP [width]
The width argument must conform to Scaling Widths. If specified, it's
saved for later paragraph left-margins; if unspecified, the saved or
default width is used.
See also HP, IP, LP, P, and PP.
UC
Sets the volume for the footer for compatibility with man pages from BSD
releases. The optional first argument specifies which release it is
from.
br
Breaks the current line. Consecutive invocations have no further effect.
See also sp.
fi
End literal mode begun by nf.
in
Indent relative to the current indentation:
.in [width]
If width is signed, the new offset is relative. Otherwise, it is
absolute. This value is reset upon the next paragraph, section, or sub-
section.
na
Don't align to the right margin.
nf
Begin literal mode: all subsequent free-form lines have their end of line
boundaries preserved. May be ended by fi.
sp
Insert vertical spaces into output with the following syntax:
.sp [height]
Insert height spaces, which must conform to Scaling Widths. If 0, this
is equivalent to the br macro. Defaults to 1, if unspecified.
See also br.
COMPATIBILITY
This section documents areas of questionable portability between
implementations of the man language.
- In quoted literals, GNU troff allowed pair-wise double-quotes to
produce a standalone double-quote in formatted output. It is not
known whether this behaviour is exhibited by other formatters.
- troff suppresses a newline before `'' macro output; in mandoc, it is
an alias for the standard `.' control character.
- The `\h' (horizontal position), `\v' (vertical position), `\m' (text
colour), `\M' (text filling colour), `\z' (zero-length character),
`\w' (string length), `\k' (horizontal position marker), `\o' (text
overstrike), and `\s' (text size) escape sequences are all discarded
in mandoc.
- The `\f' scaling unit is accepted by mandoc, but rendered as the
default unit.
- The sp macro does not accept negative values in mandoc. In GNU
troff, this would result in strange behaviour.
SEE ALSOman(1), mandoc(1), mandoc_char(7), mdoc(7), roff(7), tbl(7)HISTORY
The man language first appeared as a macro package for the roff
typesetting system in Version 7 AT&T UNIX. It was later rewritten by
James Clark as a macro package for groff. The stand-alone implementation
that is part of the mandoc(1) utility written by Kristaps Dzonsons
appeared in OpenBSD 4.6.
AUTHORS
This man reference was written by Kristaps Dzonsons <kristaps@bsd.lv>.
CAVEATS
Do not use this language. Use mdoc(7), instead.
OpenBSD 4.9 January 25, 2011 OpenBSD 4.9
