1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
|
.\" $Id: manuals.7,v 1.1 2009/04/06 20:30:40 kristaps Exp $
.\"
.\" Copyright (c) 2009 Kristaps Dzonsons <kristaps@openbsd.org>
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the
.\" above copyright notice and this permission notice appear in all
.\" copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
.\" WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
.\" AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
.\" TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
.\" PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $Mdocdate: April 6 2009 $
.Dt manuals 7
.Os
.\" SECTION
.Sh NAME
.Nm Writing UNIX Documentation
.Nd a guide to writing UNIX manuals
.\" SECTION
.Sh DESCRIPTION
.Em A utility without good documentation is of no utility at all .
.\" PARAGRAPH
.Pp
A system component's documentation describes the utility of that
component, whether it's a device driver, an executable or, most
importantly, a game.
.Pp
This document serves as a tutorial to writing
.Ux
documentation
.Pq Dq manuals .
.\" SECTION
.Sh COMPOSITION
First, copy over the manual template from
.Pa /usr/share/misc/mdoc.template
into your source directory.
.Pp
.Dl % cp /usr/share/misc/mdoc.template \.
.Pp
.Em \&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.
.\" SUBSECTION
.Ss Section Numbering
Find an appropriate section for your manual. There may exist multiple
manual names per section, so be specific:
.Pp
.\" LIST
.Bl -tag -width "XXXXXXXXXXXX" -offset indent -compact
.It Em Section
.Em Description
.It 1
operator utilities
.It 2
system calls
.It 3, 3p, 3f
programming libraries (C, Perl, Fortran)
.It 5
file and wire protocol formats
.It 6
games
.It 7
tutorials, documents and papers
.It 8
administrator utilities
.It 9
in-kernel routines
.El
.Pp
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
.Xr apropos 1 ,
then provide the
.Fl s
flag to
.Xr man 1
to see the specific section manual (section 1, in this example):
.\" DISPLAY
.Bd -literal -offset indent
% apropos myname
myname (1) - utility description
myname (3) - library description
% man \-s 1 myname
.Ed
.\" SUBSECTION
.Ss Naming
Name your component. Be terse, erring on the side of clarity. Look for
other manuals by that same name before committing:
.Pp
.Dl % apropos myname
.Pp
Manual files are named
.Pa myname.mysection ,
such as
.Pa manuals.7
for this document. Rename the template file:
.Pp
.Dl % mv mdoc.template myname.mysection
.\" SUBSECTION
.Ss Input Language
Manuals should
.Em always
be written in the
.Xr mdoc 7
formatting language.
.Pp
There exist other documentation-specific languages, such as the
historical
.Xr man 7
package of
.Xr roff 7 ;
newer languages such as DocBook or texinfo; or even ad-hoc conventions
such as README files.
.Em Avoid these formats .
.Pp
There are two canonical references for writing mdoc. Read them.
.Pp
.\" LIST
.Bl -tag -width XXXXXXXXXXXXXXXX -offset indent -compact
.It Xr mdoc 7
formal language reference
.It Xr mdoc.samples 7
macro reference
.El
.Pp
Open the template you've copied into
.Pa myname.mysection
and begin editing.
.\" SUBSECTION
.Ss Development Tools
While writing, make sure that your manual is correctly structured:
.Pp
.Dl % mandoc \-Tlint \-Wall name.1
.Pp
You may spell-check your work as follows:
.Pp
.Dl % deroff name.1 | spell
.Pp
If
.Xr ispell 1
is installed, it has a special mode for manuals:
.Pp
.Dl % ispell \-n name.1
.Pp
Use
.Xr cvs 1
or
.Xr 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:
.Pp
.Dl \&.Dd $Mdocdate: April 6 2009 $
.\" SUBSECTION
.Ss Viewing
mdoc documents may be paged to your terminal with
.Xr mandoc 1 .
If you plan on distributing your work to systems without this tool,
check it against
.Xr groff 1 :
.Bd -literal -offset indent
% mandoc \-Wall name.1 2>&1 | less
% groff -mandoc name.1 2>&1 | less
.Ed
.\" SUBSECTION
.Ss Automation
Consider adding your mdoc documents to
.Xr make 1
Makefiles in order to automatically check your input:
.Bd -literal -offset indent
\&.SUFFIXES: .1 .in
\&.in.1:
mandoc -Wall,error -Tlint $<
cp -f $< $@
.Ed
.\" SUBSECTION
.Ss Licensing
Your manual must have a license. It should be listed at the start of
your document, just as in source code.
.\" SECTION
.Sh BEST PRACTICES
The
.Xr mdoc 7
and
.Xr mdoc.samples 7
files are indispensable in guiding composition. In this section, we
introduce some
.Ux
manual best practices:
.\" SUBSECTION
.Ss Language
.Bl -enum
.It
Use clear, concise language. Favour simplicity.
.It
Write your manual in non-idiomatic English. Don't worry about
Commonwealth or American spellings \(em just correct ones.
.It
Spell-check your manual, keeping in mind short-letter terms (
.Xr iwi 4
vs.
.Xr iwn 4 ) .
.It
If you absolutely must use special characters (diacritics, mathematical
symbols and so on), use the escapes dictated in
.Xr mdoc 7 .
.El
.\" SUBSECTION
.Ss 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
.Sq \&Oo/Oc .
The same goes for function prototypes.
.Em \&Do not
use
.Sq \&Xo/Xc .
Find another way to structure your line.
.\" SUBSECTION
.Ss References
Other components may be referenced with the
.Sq \&Xr
and
.Sq \&Sx
macros. Make sure that these exist. If you intend to distribute your
manual, make sure
.Sq \&Xr
references are valid across systems (within reason). If you cross-link with
.Sq \&Sx ,
make sure that the section reference exists.
.\" SUBSECTION
.Ss Citations
Cite your work. If your system references standards documents or other
publications, please use the
.Sq \&Rs/Re
block macros.
.\" SUBSECTION
.Ss Formatting
.Em Don't style your manual .
Give it meaningful content. The front-end will worry about formatting
and style.
.\" SECTION
.Sh 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.
.Pp
.Em Manuals are part of a system component :
if you modify your code or specifications, modify the documentation.
|