1MAN(7) Linux Programmer's Manual MAN(7)
2
6 man - macros to format man pages
7
9 groff -Tascii -man file ...
10 groff -Tps -man file ...
12 man [section] title
14
16 This manual page explains the groff tmac.an macro package (often called
17 the man macro package) and related conventions for creating manual
18 (man) pages. This macro package should be used by developers when
19 writing or porting man pages for Linux. It is fairly compatible with
20 other versions of this macro package, so porting man pages should not
21 be a major problem (exceptions include the NET-2 BSD release, which
22 uses a totally different macro package called mdoc; see mdoc(7)).
23 Note that NET-2 BSD mdoc man pages can be used with groff simply by
25 specifying the -mdoc option instead of the -man option. Using the
26 -mandoc option is, however, recommended, since this will automatically
27 detect which macro package is in use.
28
30 The first command in a man page (after comment lines) should be
31 .TH title section date source manual,
33 where:
35 title The title of the man page (e.g., MAN).
37 section The section number the man page should be placed in
39 (e.g., 7).
40 date The date of the last revision—remember to change this
42 every time a change is made to the man page, since
43 this is the most general way of doing version control.
44 source The source of the command.
46 For binaries, use something like: GNU, NET-2, SLS Dis‐
48 tribution, MCC Distribution.
49 For system calls, use the version of the kernel that
51 you are currently looking at: Linux 0.99.11.
52 For library calls, use the source of the function:
54 GNU, 4.3BSD, Linux DLL 4.4.1.
55 manual The title of the manual (e.g., Linux Programmer's Man‐
57 ual).
58 Note that BSD mdoc-formatted pages begin with the Dd command, not the
60 TH command.
61 The manual sections are traditionally defined as follows:
63 1 Commands
65 Those commands that can be executed by the user from
66 within a shell.
67 2 System calls
69 Those functions which must be performed by the kernel.
70 3 Library calls
72 Most of the libc functions, such as qsort(3).
73 4 Special files
75 Files found in /dev.
76 5 File formats and conventions
78 The format for /etc/passwd and other human-readable
79 files.
80 6 Games
82 7 Conventions and miscellaneous
84 A description of the standard file system layout, net‐
85 work protocols, ASCII and other character codes, this
86 man page, and other things.
87 8 System management commands
89 Commands like mount(8), many of which only root can
90 execute.
91 9 Kernel routines
93 This is an obsolete manual section. Once it was
94 thought a good idea to document the Linux kernel here,
95 but in fact very little has been documented, and the
96 documentation that exists is outdated already. There
97 are better sources of information for kernel develop‐
98 ers.
99
101 Sections are started with .SH followed by the heading name. If the
102 name contains spaces and appears on the same line as .SH, then place
103 the heading in double quotes. Traditional or suggested headings
104 include: NAME, SYNOPSIS, DESCRIPTION, RETURN VALUE, EXIT STATUS, ERROR
105 HANDLING, ERRORS, OPTIONS, USAGE, EXAMPLES, FILES, ENVIRONMENT, DIAG‐
106 NOSTICS, SECURITY, CONFORMING TO, NOTES, BUGS, AUTHOR, and SEE ALSO.
107 Where a traditional heading would apply, please use it; this kind of
108 consistency can make the information easier to understand. However,
109 feel free to create your own headings if they make things easier to
110 understand. The only required heading is NAME, which should be the
111 first section and be followed on the next line by a one line descrip‐
112 tion of the program:
113 .SH NAME
115 chess \- the game of chess
116 It is extremely important that this format is followed, and that there
118 is a backslash before the single dash which follows the command name.
119 This syntax is used by the makewhatis(8) program to create a database
120 of short command descriptions for the whatis(1) and apropos(1) com‐
121 mands.
122 Some other traditional sections have the following contents:
124 SYNOPSIS briefly describes the command or function's interface.
126 For commands, this shows the syntax of the command and
127 its arguments (including options); boldface is used for
128 as-is text and italics are used to indicate replaceable
129 arguments. Brackets ([]) surround optional arguments,
130 vertical bars (|) separate choices, and ellipses (...)
131 can be repeated. For functions, it shows any required
132 data declarations or #include directives, followed by the
133 function declaration.
134 DESCRIPTION gives an explanation of what the command, function, or
136 format does. Discuss how it interacts with files and
137 standard input, and what it produces on standard output
138 or standard error. Omit internals and implementation
139 details unless they're critical for understanding the
140 interface. Describe the usual case; for information on
141 options use the OPTIONS section. If there is some kind
142 of input grammar or complex set of subcommands, consider
143 describing them in a separate USAGE section (and just
144 place an overview in the DESCRIPTION section).
145 RETURN VALUE gives a list of the values the library routine will
147 return to the caller and the conditions that cause these
148 values to be returned.
149 EXIT STATUS lists the possible exit status values or a program and
151 the conditions that cause these values to be returned.
152 OPTIONS describes the options accepted by the program and how
154 they change its behavior.
155 USAGE describes the grammar of any sublanguage this implements.
157 EXAMPLES provides one or more examples describing how this func‐
159 tion, file or command is used.
160 FILES lists the files the program or function uses, such as
162 configuration files, startup files, and files the program
163 directly operates on. Give the full pathname of these
164 files, and use the installation process to modify the
165 directory part to match user preferences. For many pro‐
166 grams, the default installation location is in
167 /usr/local, so your base manual page should use
168 /usr/local as the base.
169 ENVIRONMENT lists all environment variables that affect your program
171 or function and how they affect it.
172 DIAGNOSTICS gives an overview of the most common error messages and
174 how to cope with them. You don't need to explain system
175 error messages or fatal signals that can appear during
176 execution of any program unless they're special in some
177 way to your program.
178 SECURITY discusses security issues and implications. Warn about
180 configurations or environments that should be avoided,
181 commands that may have security implications, and so on,
182 especially if they aren't obvious. Discussing security
183 in a separate section isn't necessary; if it's easier to
184 understand, place security information in the other sec‐
185 tions (such as the DESCRIPTION or USAGE section). How‐
186 ever, please include security information somewhere!
187 CONFORMING TO describes any standards or conventions this implements.
189 NOTES provides miscellaneous notes.
191 BUGS lists limitations, known defects or inconveniences, and
193 other questionable activities.
194 AUTHOR lists authors of the documentation or program so you can
196 mail in bug reports.
197 SEE ALSO lists related man pages in alphabetical order, possibly
199 followed by other related pages or documents. Conven‐
200 tionally this is the last section.
201
203 Although there are many arbitrary conventions for man pages in the UNIX
204 world, the existence of several hundred Linux-specific man pages
205 defines our font standards:
206 For functions, the arguments are always specified using italics,
208 even in the SYNOPSIS section, where the rest of the function is
209 specified in bold:
210 int myfunction(int argc, char **argv);
211 Filenames are always in italics (e.g., /usr/include/stdio.h),
213 except in the SYNOPSIS section, where included files are in bold
214 (e.g., #include <stdio.h>).
215 Special macros, which are usually in upper case, are in bold
217 (e.g., MAXINT).
218 When enumerating a list of error codes, the codes are in bold
220 (this list usually uses the .TP macro).
221 Any reference to another man page (or to the subject of the cur‐
223 rent man page) is in bold. If the manual section number is
224 given, it is given in Roman (normal) font, without any spaces
225 (e.g., man(7)).
226 The commands to select the type face are:
228 .B Bold
230 .BI Bold alternating with italics (especially useful for function spec‐
232 ifications)
233 .BR Bold alternating with Roman (especially useful for referring to
235 other manual pages)
236 .I Italics
238 .IB Italics alternating with bold
240 .IR Italics alternating with Roman
242 .RB Roman alternating with bold
244 .RI Roman alternating with italics
246 .SB Small alternating with bold
248 .SM Small (useful for acronyms)
250 Traditionally, each command can have up to six arguments, but the GNU
252 implementation removes this limitation (you might still want to limit
253 yourself to 6 arguments for portability's sake). Arguments are delim‐
254 ited by spaces. Double quotes can be used to specify an argument which
255 contains spaces. All of the arguments will be printed next to each
256 other without intervening spaces, so that the .BR command can be used
257 to specify a word in bold followed by a mark of punctuation in Roman.
258 If no arguments are given, the command is applied to the following line
259 of text.
260
262 Below are other relevant macros and predefined strings. Unless noted
263 otherwise, all macros cause a break (end the current line of text).
264 Many of these macros set or use the "prevailing indent." The "prevail‐
265 ing indent" value is set by any macro with the parameter i below;
266 macros may omit i in which case the current prevailing indent will be
267 used. As a result, successive indented paragraphs can use the same
268 indent without re-specifying the indent value. A normal (non-indented)
269 paragraph resets the prevailing indent value to its default value (0.5
270 inches). By default a given indent is measured in ens; try to use ens
271 or ems as units for indents, since these will automatically adjust to
272 font size changes. The other key macro definitions are:
273 Normal Paragraphs
275 .LP Same as .PP (begin a new paragraph).
276 .P Same as .PP (begin a new paragraph).
278 .PP Begin a new paragraph and reset prevailing indent.
280 Relative Margin Indent
282 .RS i Start relative margin indent: moves the left margin i to the
283 right (if i is omitted, the prevailing indent value is used).
284 A new prevailing indent is set to 0.5 inches. As a result,
285 all following paragraph(s) will be indented until the corre‐
286 sponding .RE.
287 .RE End relative margin indent and restores the previous value of
289 the prevailing indent.
290 Indented Paragraph Macros
292 .HP i Begin paragraph with a hanging indent (the first line of the
293 paragraph is at the left margin of normal paragraphs, and the
294 rest of the paragraph's lines are indented).
295 .IP x i Indented paragraph with optional hanging tag. If the tag x is
297 omitted, the entire following paragraph is indented by i. If
298 the tag x is provided, it is hung at the left margin before
299 the following indented paragraph (this is just like .TP except
300 the tag is included with the command instead of being on the
301 following line). If the tag is too long, the text after the
302 tag will be moved down to the next line (text will not be lost
303 or garbled). For bulleted lists, use this macro with \(bu
304 (bullet) or \(em (em dash) as the tag, and for numbered lists,
305 use the number or letter followed by a period as the tag; this
306 simplifies translation to other formats.
307 .TP i Begin paragraph with hanging tag. The tag is given on the
309 next line, but its results are like those of the .IP command.
310 Hypertext Link Macros
312 (Feature supported with groff only.) In order to use hypertext link
313 macros, it is necessary to load the www.tmac macro package. Use the
314 request .mso www.tmac to do this.
315 .URL url link trailer
317 Inserts a hypertext link to the URI (URL) url, with link as
318 the text of the link. The trailer will be printed immediately
319 afterwards. When generating HTML this should translate into
320 the HTML command <A HREF="url">link</A>trailer.
321 This and other related macros are new, and many tools won't do
323 anything with them, but since many tools (including troff)
324 will simply ignore undefined macros (or at worst insert their
325 text) these are safe to insert.
326 It can be useful to define your own URL macro in manual pages
328 for the benefit of those viewing it with a roff viewer other
329 than groff. That way, the URL, link text, and trailer text
330 (if any) are still visible.
331 Here's an example:
333 .de URL
334 \\$2 \(laURL: \\$1 \(ra\\$3
335 ..
336 .if \n[.g] .mso www.tmac
337 .TH ...
338 (later in the page)
339 This software comes from the
340 .URL "http://www.gnu.org/" "GNU Project" " of the"
341 .URL "http://www.fsf.org/" "Free Software Foundation" .
342 In the above, if groff is being used, the www.tmac macro pack‐
344 age's definition of the URL macro will supersede the locally
345 defined one.
346 A number of other link macros are available. See groff_www(7) for more
348 details.
349 Miscellaneous Macros
351 .DT Reset tabs to default tab values (every 0.5 inches); does not
352 cause a break.
353 .PD d Set inter-paragraph vertical distance to d (if omitted,
355 d=0.4v); does not cause a break.
356 .SS t Subheading t (like .SH, but used for a subsection inside a
358 section).
359 Predefined Strings
361 The man package has the following predefined strings:
362 \*R Registration Symbol: ®
364 \*S Change to default font size
366 \*(Tm Trademark Symbol: ™
368 \*(lq Left angled doublequote: “
370 \*(rq Right angled doublequote: ”
372
374 Although technically man is a troff macro package, in reality a large
375 number of other tools process man page files that don't implement all
376 of troff's abilities. Thus, it's best to avoid some of troff's more
377 exotic abilities where possible to permit these other tools to work
378 correctly. Avoid using the various troff preprocessors (if you must,
379 go ahead and use tbl(1), but try to use the IP and TP commands instead
380 for two-column tables). Avoid using computations; most other tools
381 can't process them. Use simple commands that are easy to translate to
382 other formats. The following troff macros are believed to be safe
383 (though in many cases they will be ignored by translators): \", ., ad,
384 bp, br, ce, de, ds, el, ie, if, fi, ft, hy, ig, in, na, ne, nf, nh, ps,
385 so, sp, ti, tr.
386 You may also use many troff escape sequences (those sequences beginning
388 with \). When you need to include the backslash character as normal
389 text, use \e. Other sequences you may use, where x or xx are any char‐
390 acters and N is any digit, include: \', \`, \-, \., \", \%, \*x, \*(xx,
391 \(xx, \$N, \nx, \n(xx, \fx, and \f(xx. Avoid using the escape
392 sequences for drawing graphics.
393 Do not use the optional parameter for bp (break page). Use only posi‐
395 tive values for sp (vertical space). Don't define a macro (de) with
396 the same name as a macro in this or the mdoc macro package with a dif‐
397 ferent meaning; it's likely that such redefinitions will be ignored.
398 Every positive indent (in) should be paired with a matching negative
399 indent (although you should be using the RS and RE macros instead).
400 The condition test (if,ie) should only have 't' or 'n' as the condi‐
401 tion. Only translations (tr) that can be ignored should be used. Font
402 changes (ft and the \f escape sequence) should only have the values 1,
403 2, 3, 4, R, I, B, P, or CW (the ft command may also have no parame‐
404 ters).
405 If you use capabilities beyond these, check the results carefully on
407 several tools. Once you've confirmed that the additional capability is
408 safe, let the maintainer of this document know about the safe command
409 or sequence that should be added to this list.
410
412 By all means include full URLs (or URIs) in the text itself; some tools
413 such as man2html(1) can automatically turn them into hypertext links.
414 You can also use the new URL macro to identify links to related infor‐
415 mation. If you include URLs, use the full URL (e.g., <http://www.ker‐
416 nelnotes.org>) to ensure that tools can automatically find the URLs.
417 Tools processing these files should open the file and examine the first
419 non-whitespace character. A period (.) or single quote (') at the
420 beginning of a line indicates a troff-based file (such as man or mdoc).
421 A left angle bracket (<) indicates an SGML/XML-based file (such as HTML
422 or Docbook). Anything else suggests simple ASCII text (e.g., a "catman"
423 result).
424 Many man pages begin with '\" followed by a space and a list of charac‐
426 ters, indicating how the page is to be preprocessed. For portability's
427 sake to non-troff translators we recommend that you avoid using any‐
428 thing other than tbl(1), and Linux can detect that automatically. How‐
429 ever, you might want to include this information so your man page can
430 be handled by other (less capable) systems. Here are the definitions
431 of the preprocessors invoked by these characters:
432 e [22meqn(1)
434 g [22mgrap(1)
436 p [22mpic(1)
438 r [22mrefer(1)
440 t [22mtbl(1)
442 v [22mvgrind(1)
444
446 /usr/share/groff/[*/]tmac/tmac.an
447 /usr/man/whatis
448
450 Most of the macros describe formatting (e.g., font type and spacing)
451 instead of marking semantic content (e.g., this text is a reference to
452 another page), compared to formats like mdoc and DocBook (even HTML has
453 more semantic markings). This situation makes it harder to vary the
454 man format for different media, to make the formatting consistent for a
455 given media, and to automatically insert cross-references. By sticking
456 to the safe subset described above, it should be easier to automate
457 transitioning to a different reference page format in the future.
458 The Sun macro TX is not implemented.
460
462 — James Clark (jjc@jclark.com) wrote the implementation of the macro
463 package.
464 — Rickard E. Faith (faith@cs.unc.edu) wrote the initial version of
466 this manual page.
467 — Jens Schweikhardt (schweikh@noc.fdn.de) wrote the Linux Man-Page
469 Mini-HOWTO (which influenced this manual page).
470 — David A. Wheeler (dwheeler@ida.org) heavily modified this manual
472 page, such as adding detailed information on sections and macros.
473
475 apropos(1), groff(1), man(1), man2html(1), mdoc(7), mdoc.samples(7),
476 groff_man(7), groff_www(7), whatis(1)
477Linux 2004-07-27 MAN(7)