1 .Dd $Mdocdate: March 22 2009 $
6 .Nm Writing UNIX Documentation
7 .Nd a guide to writing UNIX manuals
10 .Em A utility without good documentation is of no utility at all .
13 A system component's documentation describes the utility of that
14 component, whether it's a device driver, an executable or, most
15 importantly, a game. Although there are plenty of documents available
18 documents, or where to find them, few focus on composition.
21 This document serves as a tutorial to writing
25 If you add something to your operating system, whether it's a new file
26 format or directory structure or device driver, it needs documentation.
29 Classify your system component. In
33 which categorises the component's function. The section of a manual is
34 usually listed in parenthesis next to the component name, such as
36 section 1. You can query a manual explicitly by its section:
40 The following table lists broad classifications and the applicable
44 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
60 Consists of hardware (and pseudo-) device driver documentation. Drivers
61 are unilaterally classified in section 4.
63 these manuals are necessarily system- and architecture-specific.
68 .Bl -tag -width "File-formatX" -offset indent -compact
72 DEC/Intel 10/100 Ethernet device
76 Executables consist of runnable binaries. They're further classified by
80 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
86 administrator utilities
94 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
98 modify user login information
106 Function documentation describes programme source code, whether in the
107 form of libraries, modules or standalone sources. They're further
108 classified by context:
111 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
117 programming libraries (C, Perl, Fortran)
123 section 2 and 9 manuals are necessarily system- and often
124 architecture-specific. Examples:
127 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
131 open or create a file for reading or writing
133 whitespace character test
135 convert POD data to formatted roff
137 process context sleep
141 A file format usually describes the format of on-disc binary or text
142 data, although it can also be used to describe wire protocols (this is
143 usually best left to RFC). These manuals are unilaterally classified in
149 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
153 format of the password file
157 Documents with no other classification are relegated to section 7. This
158 constitutes reference tutorials (such as this document) and other
159 miscellaneous information.
164 .Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
170 symbolic link handling
174 Prepare your composition environment.
177 Your component will need a name by which to query its contents via
179 Keep it simple. You may want to look for other manuals by that same
180 name before committing:
184 Conventionally, manual files are named
197 There exist other documentation-specific languages, such as the
205 newer languages such as DocBook, texinfo or schema-driven XML; or even
206 ad-hoc conventions such as README files.
207 .Em Stay away from these methods!
208 Historical formats fail to capture a manual's semantic content, instead
209 only modelling its style. Newer methods requires special,
210 system-specific tools and may change or become obsolete over the
211 life-time of your component.
213 There are two canonical references for writing mdoc manuals:
216 .Bl -tag -width XXXXXXXXXXXXXXXX -offset indent -compact
218 formal language reference
219 .It Xr mdoc.samples 7
223 Don't merely copy existing manuals! Most systems distribute an mdoc
224 template to help you get started in
225 .Pa /usr/share/misc/mdoc.template .
227 .Ss Development Tools
228 While writing, make sure that your manual is correctly structured:
230 .Dl % mandoc \-Tlint \-Wall name.1
232 You may spell-check your work as follows:
234 .Dl % deroff name.1 | spell
235 .Dl % ispell \-n name.1
239 or, if not available,
241 to version-control your work. If you wish the last check-in to effect
242 your document's date, use the following RCS tag for the date macro:
244 .Dl \&.Dd $Mdocdate: March 22 2009 $
248 mdoc documents may be paged to your terminal with traditional
252 or with newer, more powerful tools such as
255 .Bd -literal -offset indent
256 % nroff \-mandoc name.1 | less
257 % groff \-Tascii \-mandoc name.1 | less
258 % mandoc name.1 | less
261 Other output formats are also supported:
263 .Bd -literal -offset indent
264 % groff \-Tps \-mandoc name.1 | less
265 % mandoc \-Thtml name.1 | less
269 Consider adding your mdoc documents to
271 Makefiles in order to automatically check your input and generate
273 .Bd -literal -offset indent
274 \&.SUFFIXES: .html .txt .1 .in
277 mandoc -Wall,error -Tlint $<
284 mandoc -Tascii $< | col -b >$@
292 files will be indispensable in guiding composition. In this section, we
295 manual best practices:
300 Use clear, concise language. Favour simplicity.
302 Write your manual in non-idiomatic English. Don't worry about
303 Commonwealth or American spellings \(em just correct ones.
305 Spell-check your manual, keeping in mind short-letter terms (
310 If you absolutely must use special characters (diacritics, mathematical
311 symbols and so on), use the escapes dictated in
316 Other components may be referenced with the
320 macros. Make sure that these exist. If you intend to distribute your
323 references are valid across systems (within reason). If you cross-link with
325 make sure that the section reference exists.
328 Cite your work. If your system references standards documents or other
329 publications, please use the
333 .Ss Types and Prototypes
334 If writing section 3 manuals, make sure that you correctly annotate your
335 variables and functions. This guarantees that cross-referncing between
336 function names and their prototypes works properly.