OSDN Git Service

(split) Convert release and draft pages to UTF-8.
[linuxjm/LDP_man-pages.git] / release / man7 / man-pages.7
1 .\" (C) Copyright 1992-1999 Rickard E. Faith and David A. Wheeler
2 .\" (faith@cs.unc.edu and dwheeler@ida.org)
3 .\" and (C) Copyright 2007 Michael Kerrisk <mtk.manpages@gmail.com>
4 .\"
5 .\" Permission is granted to make and distribute verbatim copies of this
6 .\" manual provided the copyright notice and this permission notice are
7 .\" preserved on all copies.
8 .\"
9 .\" Permission is granted to copy and distribute modified versions of this
10 .\" manual under the conditions for verbatim copying, provided that the
11 .\" entire resulting derived work is distributed under the terms of a
12 .\" permission notice identical to this one.
13 .\"
14 .\" Since the Linux kernel and libraries are constantly changing, this
15 .\" manual page may be incorrect or out-of-date.  The author(s) assume no
16 .\" responsibility for errors or omissions, or for damages resulting from
17 .\" the use of the information contained herein.  The author(s) may not
18 .\" have taken the same level of care in the production of this manual,
19 .\" which is licensed free of charge, as they might when working
20 .\" professionally.
21 .\"
22 .\" Formatted or processed versions of this manual, if unaccompanied by
23 .\" the source, must acknowledge the copyright and authors of this work.
24 .\"
25 .\" 2007-05-30 created by mtk, using text from old man.7 plus
26 .\" rewrites and additional text.
27 .\"
28 .\" Japanese Version Copyright (c) 2007  Akihiro MOTOKI
29 .\"         all rights reserved.
30 .\" Translated 2007-06-13, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>, LDP v2.54
31 .\" Updated 2007-07-04, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>, LDP v2.59
32 .\" Updated 2007-09-03, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>, LDP v2.64
33 .\" Updated 2008-08-09, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>, LDP v3.05
34 .\" 
35 .TH MAN-PAGES 7 2008-10-28 "Linux" "Linux Programmer's Manual"
36 .SH 名前
37 man-pages \- Linux の man ページを書く際の決まり事
38 .SH 書式
39 .B man
40 .RI [ section ]
41 .I title
42 .SH 説明
43 このページでは、
44 Linux \fIman-pages\fP プロジェクトのマニュアルページを書く際に
45 従うべき決まり事について説明する。
46 Linux \fIman-pages\fP は Linux のマニュアルページの
47 セクション 2, 3, 4, 5, 7 から構成されている。
48 このページで説明されている決まり事は、他のプロジェクトの
49 マニュアルページを書く作者にも役立つことだろう。
50 .SS マニュアルページのセクション
51 .PP
52 マニュアルのセクションは、習慣的に以下のような定義が用いられている:
53 .TP 10
54 .B 1 コマンド (プログラム)
55 シェルの中からユーザが実行できるコマンド。
56 .TP
57 .B 2 システムコール
58 カーネルが処理しなければならない関数。
59 .TP
60 .B 3 ライブラリコール
61 .I libc
62 の関数の大部分。
63 .TP
64 .B 4 スペシャルファイル (デバイス)
65 .I /dev
66 以下にあるファイル。
67 .TP
68 .B 5 ファイルのフォーマットと規約
69 .I /etc/passwd
70 などの人が読めるファイルのフォーマット。
71 .TP
72 .B 6 ゲーム
73 .TP
74 .B 7 約束事その他
75 様々な事柄の概要、慣習、プロトコル、文字集合の規格、その他雑多なこと。
76 .TP
77 .B 8 システム管理コマンド
78 .BR mount (8)
79 のような root のみが実行可能なコマンド。
80 .\" .TP
81 .\" .B 9 カーネルルーチン
82 .\" このマニュアルセクションは廃止された。
83 .\" かつてはここに Linux カーネルのドキュメントを置くのが良いことだと
84 .\" 考えられていた。しかし、文書化されたものは非常に少なく、
85 .\" またそれらもすでに古いものとなってしまった。
86 .\" カーネル開発者にとって、もっとよい情報源が他にあるだろう。
87 .SS マクロパッケージ
88 新しいマニュアルページは
89 .BR man (7)
90 で説明されている
91 .B groff an.tmac
92 パッケージを使って記述すべきである。
93 この方針は一貫性の確保が主な理由である。既存の Linux のマニュアルページ
94 の圧倒的多数がこれらのマクロを使って記述されている。
95 .SS ソースファイルの配置に関する決まり事
96 マニュアルページのソースコードの 1行の長さは
97 可能な限り 75文字を越えないようにしてほしい。
98 こうすることで、パッチをメール本文に載せて送る場合に、
99 メールクライアントによる行折り返しを回避することができる。
100
101 新しい文は行頭から開始する。
102 これにより、パッチの内容を確認しやすくなる。
103 パッチは文単位であることが多いからである。
104 .SS タイトル行
105 man ページの最初の行は \fBTH\fP コマンドにすべきである。
106 .RS
107 .sp
108 .B \&.TH
109 .I "title section date source manual"
110 .sp
111 .RE
112 個々の説明:
113 .RS
114 .TP 10
115 .I title
116 man ページのタイトル。全部大文字で記載する (例:
117 .IR MAN-PAGES )。
118 .TP
119 .I section
120 man ページが属するセクション番号 (例:
121 .IR 7 )。
122 .TP
123 .I date
124 最新のリビジョンの日付\(emman ページに変更を加えたときには
125 必ずこれを変更すること。
126 これが最も一般的なバージョン管理方法である。
127 日付は YYYY-MM-DD の形式で記載すべきである。
128 .TP
129 .I source
130 コマンド、関数、システムコールの出自。
131
132 数少ないセクション 1 と 8 のページの場合、おそらく単に
133 .I GNU
134 とだけ書くことが多いだろう。
135
136 システムコールの場合、単に
137 .I "Linux"
138 とだけ書く。
139 (以前の慣習では、マニュアルページを記載した/内容を確認したカーネルの
140 バージョン番号を記載していた。しかし、バージョン番号が実際の内容と
141 一致していることはなく、そのためバージョン番号がないよりも
142 おそらく悪い形になっていた。
143 今後は、バージョン番号を含めるのは避けること。)
144
145 glibc のライブラリコールや
146 その他の一般的な GNU ライブラリのライブラリコールの場合、
147 単に
148 .IR "GNU C Library" ", " GNU
149 と書くか、空の文字列を使う。
150
151 セクション 4 のページでは
152 .I "Linux"
153 を使う。
154
155 よくわからない場合は、
156 .I Linux
157 とか
158 .I GNU
159 と書いておく。
160 .TP
161 .I manual
162 マニュアルのタイトル (例:
163 \fIman-pages\fP パッケージのセクション 2 および 3 のページの場合には、
164 .I "Linux Programmer's Manual"
165 を使うこと)。
166 .RE
167 .SS マニュアルページのセクション
168 昔から使われてきたセクション名を以下のリストに示す。
169 これらを使うと良いだろう。
170 一般的に、マニュアルページは、少なくとも
171 .B 色つき
172 のセクションを持つのが望ましい。
173 新しくマニュアルページを作成する際には、だいたい以下のリストに示した
174 順序でセクションを配置するようにしてもらいたい。
175 .in +0.5i
176 .nf
177
178 \fB名前\fP
179 \fB書式\fP
180 設定               [通常はセクション 4 のみ]
181 \fB説明\fP
182 オプション         [通常はセクション 1, 8 のみ]
183 終了ステータス     [通常はセクション 1, 8 のみ]
184 返り値             [通常はセクション 2, 3 のみ]
185 .\" May 07: Few current man pages have an ERROR HANDLING section,,,
186 .\" エラー処理
187 エラー             [たいていはセクション 2, 3 のみ]
188 .\" May 07: Almost no current man pages have a USAGE section,,,
189 .\" 利用法
190 .\" 診断メッセージ
191 .\" May 07: Almost no current man pages have a SECURITY section,,,
192 .\" セキュリティ
193 環境変数
194 ファイル
195 バージョン         [通常はセクション 2, 3 のみ]
196 準拠
197 注意/備考
198 バグ
199
200 .\" 著者 セクションは非推奨である
201 .\" 著者
202 \fB関連項目\fP
203
204 .fi
205 .in
206 「伝統的に使われてきた見出しが使える場合には、それを使ってほしい。」
207 この種の一貫性を保つことで、情報を理解しやすくなるからである。
208 どうしても必要な場合には、理解しやすくなるように独自の見出しを
209 作ってもよい (特にセクション 4 や 5 のページではこうした方が
210 わかりやすくなる)。ただし、そうする前に、伝統的な見出しを使い、
211 そのセクション内にサブセクション (\fI.SS\fP) を設けることで
212 対応できないか考えてほしい。
213
214 以下のリストでは、上記のセクションのそれぞれの内容について
215 詳しく説明する。
216 .TP 14
217 .B 名前 (NAME)
218 そのマニュアルページの名前。
219 \fB.SH NAME\fP コマンドの行が従うべき大事な点については
220 .BR man (7)
221 を参照してほしい。
222 .TP
223 .B 書式 (SYNOPSIS)
224 コマンドや関数のインターフェースを簡潔に記述する。
225 コマンドに対しては、コマンドや引き数 (オプション) の文法を書く。
226 そのまま書くテキストにはボールド体を用い、置き換える引き数には
227 イタリック体を用いる。省略可能なオプションはブラケット ([]) で囲い、
228 選択肢は縦棒 (|) で区切り、繰り返しには省略符号 (...) を書く。
229 関数に対しては、必要なデータ宣言や
230 .B #include
231 指定を書き、関数宣言を続ける。
232
233 ヘッダファイルから関数 (や変数) の定義を得るために
234 機能検査マクロ (feature test macro) を定義しなければならない場合、
235 書式 (SYNOPSIS) に必要な機能検査マクロを記載すべきである。
236 機能検査マクロについては
237 .BR feature_test_macros (7)
238 で説明されている。
239 .\" FIXME . Say something here about compiler options
240 .TP
241 .B CONFIGURATION
242 デバイスの設定詳細。
243 通常、このセクションは 4 章のマニュアルページでのみ登場する。
244 .TP
245 .B 説明 (DESCRIPTION)
246 プログラム・関数・フォーマットの動作・目的を説明する。
247 ファイルや標準入力をどのように処理し、標準出力や標準エラー出力を
248 どのように生成するかといったことについて述べる。
249 内部動作や実装の詳細については省略する
250 (ただしそれが動作の理解にどうしても必要なら別)。
251 通常の場合について記述する。
252 プログラムのコマンドライン・オプションの説明には、
253 .B オプション
254 のセクションを用いる。
255 .\" 入力にある種の文法があったり、複雑なサブコマンドがある場合は、
256 .\" それらは
257 .\" .B 利用法
258 .\" のセクションに分離することを考えるとよい
259 .\" .RB ( 説明
260 .\" のセクションには概要だけを置くようにする)。
261 .TP
262 .B オプション (OPTIONS)
263 プログラムが受け付けるコマンドライン・オプションと、
264 その場合プログラムの振舞いがどう変わるかを説明する。
265 このセクションはセクション 1 と 8 のマニュアルページにだけ登場すべきである。
266 .\" .TP
267 .\" .B 利用法 (USAGE)
268 .\" コマンドなどが実装している副言語 (sublanguage) の文法を記述する。
269 .TP
270 .B 終了ステータス (EXIT STATUS)
271 プログラムの終了ステータスの値と、それらの値に対応する状況を列挙する。
272 このセクションはセクション 1 と 8 のマニュアルページにだけ登場すべきである。
273 .TP
274 .B 返り値 (RETURN VALUE)
275 セクション 2 と 3 のページの場合、このセクションに
276 ライブラリルーチンが呼び出し元に返す値のリストを記載する。
277 それらの値が返された場合の状態に対する説明も書く。
278 .TP
279 .B エラー (ERRORS)
280 セクション 2 と 3 のマニュアルページでは、
281 エラーが発生した場合に
282 .I errno
283 に設定される可能性がある値のリストを記載する。
284 リストには、エラーの値とエラーの原因についての情報を書く。
285 「エラーリストはアルファベット順にすべきである。」
286 .TP
287 .B 環境変数 (ENVIRONMENT)
288 プログラムや関数に影響する環境変数をリストし、それらの効果を書く。
289 .TP
290 .B ファイル (FILES)
291 プログラムや関数が用いるファイルを列記する。
292 例えば、設定ファイル、起動ファイル、プログラムが直接操作するファイルなどである。
293 これらのファイルのファイル名はフルパスで記載し、
294 ディレクトリの部分はユーザーの好みに合わせて
295 インストール処理で変更できるようにする。
296 多くのプログラムではデフォルトのインストール先は
297 .I /usr/local
298 である。したがってベースとなるマニュアルページでも
299 .I /usr/local
300 が使われていることが多いだろう。
301 .\" May 07: Almost no current man pages have a DIAGNOSTICS section;
302 .\"         "RETURN VALUE" or "EXIT STATUS" is preferred.
303 .\" .TP
304 .\" .B 診断メッセージ (DIAGNOSTICS)
305 .\" ごく一般的なエラーメッセージの概要と、
306 .\" それらをどう扱うかについて述べる。プログラムの実行時に現れる
307 .\" システムエラーメッセージや致命的シグナルを全部説明する必要はない。
308 .\" ただしそれらがプログラムに対して
309 .\" 何らかの特殊な意味を持っている場合は別である。
310 .\"
311 .\" May 07: Almost no current man pages have a SECURITY section.
312 .\".TP
313 .\" .B セキュリティ (SECURITY)
314 .\" セキュリティ関連の話題・問題について述べる。
315 .\" 避けるべき設定や環境・セキュリティ上の問題を引き起こすコマンド
316 .\" などについて警告する。それらが明らかでない場合には、これは特に重要である。
317 .\" セキュリティに関する話題は、必ずしも独立したセクションにする必要はない。
318 .\" もし理解しやすければ、セキュリティの情報は他のセクション
319 .\" (例えば
320 .\" .B 説明
321 .\" や
322 .\" .B 利用法
323 .\" など) に書いてもよい。
324 .\" しかし、セキュリティの情報はどこかには書いておいてほしい!
325 .TP
326 .B バージョン (VERSIONS)
327 システムコールやライブラリ関数が登場したり、動作の重要な変更が行われた、
328 Linux カーネルや glibc のバージョンについての簡潔な概要。
329 一般に、全ての新しいインターフェイスは、マニュアルページに
330 「バージョン」の節を設けるべきである。
331 残念なことに、多くの既存のマニュアルページにこの情報は含まれていない
332 (これらのページが書かれた時点ではそのようなポリシーはなかったからである)。
333 これを改善するパッチは歓迎されるが、
334 新しいコードを書くプログラマの観点からすれば、
335 おそらくこの情報が重要になるのは、
336 Linux 2.4 以降で追加されたカーネルインターフェイス (カーネル 2.2 からの変更) と
337 glibc バージョン 2.1 以降で追加されたライブラリ関数 (glibc 2.0 からの変更)
338 についてのみであろう。
339
340 .BR syscalls (2)
341 マニュアルページにも、いろいろなシステムコールが初めて登場した
342 カーネルバージョンについての情報が書かれている。
343 .TP
344 .B 準拠 (CONFORMING TO)
345 そのマニュアルページで説明している関数やコマンドに関連する
346 標準規格や慣習について記載する。
347 セクション 2 や 3 のページでは、このセクションで
348 システムコールや関数が準拠する POSIX.1 のバージョンと、
349 C99 で規定されているかに触れるべきである。
350 (SUS, SUSv2, XPG などの他の標準規格や、SVr4 や 4.xBSD の実装標準に
351 ついては、説明しているコールがこれらの規格で規定されており
352 POSIX.1 の現行バージョンで規定されていない場合以外は、
353 あまり深く気にする必要はない。)
354 .RB ( standards (7)
355 参照。)
356
357 そのコールがどの標準にも基づいていないが、
358 他のシステムで広く存在する場合は、その旨を記載すること。
359 そのコールが Linux 固有の場合は、その旨を記載すること。
360
361 (そうなっているページが多いが) このセクションの内容が標準のリスト
362 だけの場合、リストの最後にピリオド (\(aq.\(aq) を置くこと。
363 .TP
364 .B 注意 (NOTES)
365 その他の注意点を書く。
366 セクション 2 と 3 のマニュアルページでは、
367 \fILinux での注意 (Linux Notes)\fP や \fIglibc での注意 (Glibc Notes)\fP
368 という名前のサブセクション (\fBSS\fP) を設けると便利なこともある。
369 .TP
370 .B バグ (BUGS)
371 制限・知られている欠陥や不便な点、その他不思議な動作などを書く。
372 .TP
373 .B 例 (EXAMPLE)
374 この関数・ファイル・コマンドをどのように使うかを示した
375 ひとつまたは複数の例を記述する。
376 サンプルプログラムを書く際の詳細は
377 以下の「サンプルプログラム」の節を参照のこと。
378 .TP
379 .B 著者 (AUTHORS)
380 文書またはプログラムの著者を列記する。
381 .B 著者セクションは極力使用しないこと。
382 一般的には、著者のリストを各ページに撒き散らさない方がよい
383 (時間がたつと、作者のリストは膨大になる可能性がある)。
384 マニュアルページを新規に書いたり、大幅に修正を行った場合には、
385 ソースファイルにコメントとして著作権表示を追加すること。
386 あなたがデバイスドライバの作者で、バグを報告するためのアドレスを
387 載せたい場合は、「バグ」セクションの後ろにこのセクションを配置すること。
388 .TP
389 .B 関連項目 (SEE ALSO)
390 関連するマニュアルページを、コンマ区切りのリストで、
391 セクション番号順に、セクション内ではアルファベット順で記載する。
392 可能なら関連する他の文書も書く。
393 慣習では、このセクションは最後に置く。
394 リストの末尾にピリオドを置かないこと。
395 .SS フォントの慣習
396 .PP
397 関数に対しては、引き数には常にイタリック体を用いる。
398 「たとえ書式 (SYNOPSIS) セクションであっても、このルールに従う」
399 関数の他の部分はボールドを指定する:
400 .PP
401 .BI "    int myfunction(int " argc ", char **" argv );
402 .PP
403 引き数名といった変数名はイタリック体を指定すべきである。
404 .PP
405 ファイル名 (パス名、または
406 .I /usr/include
407 ディレクトリ内のファイルへの参照) は常にイタリック体にする (例:
408 .IR <stdio.h> )。
409 ただし、書式 (SYNOPSIS) セクションは例外で、
410 インクルードファイルはボールドにする (例:
411 .BR "#include <stdio.h>" )。
412 .I /usr/include
413 以下の標準のインクルードファイルを参照する際は、
414 通常の C 言語と同様に山括弧でヘッダファイルを囲ぬで指定する (例:
415 .IR <stdio.h> )。
416 .PP
417 通常、大文字で表現する特殊マクロはボールドで表す (例えば
418 .BR MAXINT )。
419 例外として NULL はボールドにしない。
420 .PP
421 エラーコードのリストを列挙する時には、コードはボールドで表す
422 (このリストには通常
423 .B \&.TP
424 マクロを用いる)。
425 .PP
426 完全なコマンドは、長い場合には、例に示すように
427 字下げした行にコマンドだけを記載すべきである。
428 .in +4n
429 .nf
430
431 man 7 man-pages
432
433 .fi
434 .in
435 コマンドが短い場合は、
436 .I "man 7 man-pages"
437 のようにイタリック体で文中に埋め込んで記載してもよい。
438 この場合、コマンド内の適切な位置に、改行できないスペース ("\e\ ")
439 を使うとよいかもしれない。
440 コマンドオプションも
441 .I \-l
442 のようにイタリック体で記載すべきである。
443 .PP
444 式は、専用の字下げした行に記載しない場合、イタリック体を指定すること。
445 繰り返しになるが、式を通常の文中に埋め込む場合にも、
446 改行できないスペースを使うとよいだろう。
447 .PP
448 そのマニュアルページの説明対象への参照は、ボールドで名前を記載する。
449 対象が関数 (つまり、セクション 2 や 3 のページ) の場合、
450 名前の後ろにローマンフォント (通常のフォント) で丸括弧の対を続ける。
451 例えば、
452 .BR fcntl (2)
453 のマニュアルページでは、説明対象への参照は
454 .BR fcntl ()
455 のように記載する。
456 マニュアルページのソースファイルには次のように記載するのが望ましい:
457 .nf
458
459     .BR fcntl ()
460
461 .fi
462 ("\\fB...\\fP()" よりも、この形式を使うこと。
463 これにより、マニュアルページのソースファイルを解釈するツールを
464 書くのが簡単になる。)
465 .PP
466 別のマニュアルページへの参照は、ボールドで名前を記載し、
467 それに続けてセクション番号を「必ず」書く。セクション番号は
468 ローマンフォント (通常のフォント) で書き、スペースは入れない
469 (例:
470 .BR intro (2))。
471 マニュアルページのソースファイルには次のように記載するのが望ましい:
472 .nf
473
474     .BR intro (2)
475
476 .fi
477 (相互参照にセクション番号を含めておくと、
478 .B man2html
479 といったツールがページ間のハイパーリンクを適切に生成できる。)
480 .SS 綴り (spelling)
481 リリース 2.59 からだが、
482 .I man-pages
483 はアメリカ英語の綴りの慣習に従っている。
484 新しいページやパッチは全てこの慣習に従って下さい。
485 .SS サンプルプログラムとシェルのセッション
486 マニュアルページには、システムコールやライブラリ関数の使い方を示す
487 サンプルプログラムを含めることができる。
488 その際には、以下の点に留意すべきである。
489 .TP 3
490 *
491 サンプルプログラムは C で記載すること。
492 .TP
493 *
494 サンプルプログラムは、
495 インタフェースについて文章で簡単に説明できる以上のことを示す場合にだけ
496 必要かつ有用である。インタフェースを呼び出す以外に何もしないサンプル
497 プログラムは普通はほとんど役に立たない。
498 .TP
499 *
500 サンプルプログラムはかなり短めにすること
501 (100行未満が望ましく、50行未満が理想的である)。
502 .TP
503 *
504 サンプルプログラムでは、システムコールやライブラリ関数を呼び出した後で
505 エラーチェックを行うこと。
506 .TP
507 *
508 サンプルプログラムは完結していて、
509 \fIcc\ \-Wall\fP
510 でコンパイルした際に警告なしでコンパイルできること。
511 .TP
512 *
513 可能かつ適切な場合には、サンプルプログラムで
514 入力により動作を変化させるなどの実験を行うとよい
515 (理想的には、コマンドライン引き数や、プログラムが読み込む入力データ
516 経由で、動作を変化させるのがよい)。
517 .TP
518 *
519 サンプルプログラムは、K&R (Kernighan and Ritchie) スタイルで書き、
520 字下げはスペース 4文字で行う。
521 (ソースコードで TAB 文字を使うのは避けること。)
522 .PP
523 サンプルプログラムがどんな風になっていればよいかの例については、
524 .BR wait (2)
525
526 .BR pipe (2)
527 を参照すること。
528
529 プログラムの使い方や他のシステムの特徴を示すためにシェルのセッション例
530 を含める場合、ユーザの入力文をボールドにして、システムが生成する
531 出力と区別できるようにすること。
532 .SS 構造体の定義、シェルのセッションログなどの字下げ
533 構造体の定義やシェルのセッションログなどを本文中に記載する際は、
534 スペース 4個分の字下げを行う (つまり、ブロックを
535 .I ".in\ +4n"
536
537 .I ".in"
538 で囲む)。
539 .SH 例
540 .I man-pages
541 パッケージに含まれるマニュアルページの体裁の標準的な例については、
542 .BR pipe (2)
543
544 .BR fcntl (2)
545 を参照すること。
546 .SH 関連項目
547 .BR man (1),
548 .BR man2html (1),
549 .BR groff (7),
550 .BR groff_man (7),
551 .BR man (7),
552 .BR mdoc (7)