MANUALS(7)

NAME

Writing UNIX Documentation — a guide to writing UNIX manuals

DESCRIPTION

A utility without good documentation is of no utility at all.

A system component's documentation describes the utility of that component, whether it's a device driver, an executable or, most importantly, a game.

This document serves as a tutorial to writing UNIX documentation (“manuals”).

ENVIRONMENT

First, copy over the manual template from /usr/share/misc/mdoc.template into your source directory.

% cp /usr/share/misc/mdoc.template .

Do not start afresh or by copying another manual unless you know exactly what you're doing! If the template doesn't exist, bug your administrator.

Section Numbering

Find an appropriate section for your manual. There may exist multiple manual names per section, so be specific:

Section

Description

operator utilities

system calls

3, 3p, 3f

programming libraries (C, Perl, Fortran)

file and wire protocol formats

games

tutorials, documents and papers

administrator utilities

in-kernel routines

If your manual falls into multiple categories, choose the most widely-used or, better, re-consider the topic of your manual to be more specific. You can list all manuals per section by invoking apropos(1), then provide the -s flag to man(1) to see the specific section manual (section 1, in this example):

% apropos myname 
myname (1) - utility description 
myname (3) - library description 
% man -s 1 myname

Naming

Name your component. Be terse, erring on the side of clarity. Look for other manuals by that same name before committing:

% apropos myname

Manual files are named myname.mysection, such as manuals.7 for this document. Rename the template file:

% mv mdoc.template myname.mysection

Development Tools

While writing, make sure that your manual is correctly structured:

% mandoc -Tlint -Wall -fstrict name.1

The quick-fix feature of vim(1) is useful for checking over many manuals:

% mandoc -Wall -fstrict -Tlint -fign-errors \ 
  ./path/to/manuals/* 2>&1 > /tmp/mandoc.errs 
% vim -q /tmp/mandoc.errs

You may spell-check your work as follows:

% deroff name.1 | spell

If ispell(1) is installed, it has a special mode for manuals:

% ispell -n name.1

Use cvs(1) or rcs(1) to version-control your work. If you wish the last check-in to effect your document's date, use the following RCS tag for the date macro:

.Dd $Mdocdate: April 13 2010 $

Viewing

mdoc documents may be paged to your terminal with mandoc(1). If you plan on distributing your work to systems without this tool, check it against groff(1):

% mandoc -Wall name.1 2>&1 | less 
% groff -mandoc name.1 2>&1 | less

Automation

Consider adding your mdoc documents to make(1) Makefiles in order to automatically check your input:

.SUFFIXES: .1 .in 
 
.in.1: 
	mandoc -Wall,error -Tlint $< 
	cp -f $< $@

Licensing

Your manual must have a license. It should be listed at the start of your document, just as in source code.

COMPOSITION

Manuals should always be written in the mdoc(7) formatting language.

Open the template you've copied into myname.mysection and begin editing.

Language

Use clear, concise language. Favour simplicity.

Write your manual in non-idiomatic English. Don't worry about Commonwealth or American spellings — just correct ones.

Spell-check your manual, keeping in mind short-letter terms ( iwi(4) vs. iwn(4)).

If you absolutely must use special characters (diacritics, mathematical symbols and so on), use the escapes dictated in mdoc(7).

Style

The structure of the mdoc language makes it very hard to have any particular format style. Keep your lines under 72 characters in length. If you must have long option lines, use ‘Oo/Oc'. The same goes for function prototypes. Do not use ‘Xo/Xc'. Find another way to structure your line.

References

Other components may be referenced with the ‘Xr' and ‘Sx' macros. Make sure that these exist. If you intend to distribute your manual, make sure ‘Xr' references are valid across systems (within reason). If you cross-link with ‘Sx', make sure that the section reference exists.

Citations

Cite your work. If your system references standards documents or other publications, please use the ‘Rs/Re' block macros.

Formatting

Don't style your manual. Give it meaningful content. The front-end will worry about formatting and style.

MAINTENANCE

As your component changes and bugs are fixed, your manual may become out of date. You may be tempted to use tools like Doxygen to automate the development of your manuals. Don't.

Manuals are part of a system component: if you modify your code or specifications, modify the documentation.