そのラッパー関数がシステムコールを呼び出すのに必要な処理を実行する。 そのため、システムコールを呼び出すのは通常のライブラリ関数を呼び出すのと
同じように見える。
-In many cases, the C library wrapper function does nothing more than:
+多くの場合、 C ライブラリのラッパー関数が行うのは以下のことだけである。
.IP * 3
-copying arguments and the unique system call number to the registers where
-the kernel expects them;
+引き数と一意なシステムコール番号をカーネルが期待するレジスターにコピーする
.IP *
-trapping to kernel mode, at which point the kernel does the real work of the
-system call; and
+カーネルがシステムコールの実際の処理を行う時点でカーネルモードに入る
.IP *
-setting \fIerrno\fP if the system call returns an error number when the kernel
-returns the CPU to user mode.
+カーネルが CPU をユーザーモードに返した際にシステムコールがエラー番号を返したいれば \fIerrno\fP を設定する
.LP
-However, in a few cases, a wrapper function may do rather more than this,
-for example, performing some preprocessing of the arguments of arguments
-before trapping to kernel mode, or postprocessing of values returned by the
-system call. Where this is the case, the manual pages in Section 2
-generally try to note the details of both the (usually GNU) C library API
-interface and the raw system call. Most commonly, the main DESCRIPTION will
-focus on the C library interface, and differences for the system call are
-covered in the NOTES section.
+しかし、ラッパー関数がこれ以上のことを行う場合もいくつかある。例えば、カーネルモードに入る前に引き数に対する前処理を実行したり、システムコールが返した値に対する後処理を行うなどである。このような場合、セクション
+2 のマニュアルページでは、基本的に、C ライブラリ API インターフェース (通常は GNU C ライブラリのもの)
+と生のシステムコールの両方の詳細をできるだけ説明しようとする。ほとんどの場合、メインとなる「説明」では C
+ライブラリのインターフェースに焦点をあてて説明し、システムコールでの差分については「注意」のセクションに説明がある。
Linux のシステムコールのリストについては \fBsyscalls\fP(2) を参照のこと。
.SH 返り値
\fI_FILE_OFFSET_BITS=64\fP を利用すること。
.TP
\fB_LARGEFILE_SOURCE\fP
-This macro was historically used to expose certain functions (specifically
-\fBfseeko\fP(3) and \fBftello\fP(3)) that address limitations of earlier APIs
-(\fBfeek\fP(3) and \fBftell\fP(3)) that use \fIlong int\fP for file offsets. This
-macro is implicitly defined if \fB_XOPEN_SOURCE\fP is defined with a value
-greater than or equal to 500. New programs should not employ this macro;
-defining \fB_XOPEN_SOURCE\fP as just described or defining \fB_FILE_OFFSET_BITS\fP
-with the value 64 is the preferred mechanism to achieve the same result.
+このマクロは、歴史的には、ファイルオフセットで \fIlong int\fP を使う以前の API (\fBfseek\fP(3) や \fBftell\fP(3))
+の制限を解決する関数 (特に \fBfseeko\fP(3) と \fBftello\fP(3)) を公開するのに使われていた。 このマクロは
+\fB_XOPEN_SOURCE\fP が 500 以上の値で定義されている場合に暗黙のうちに定義される。
+新しいプログラムでぇあこのマクロは使用すべきではない。 \fB_XOPEN_SOURCE\fP をただ定義するか、 \fB_FILE_OFFSET_BITS\fP
+を値 64 で定義するのが、同じ結果を得るための推奨される方法である。
.TP
\fB_FILE_OFFSET_BITS\fP
このマクロを値 64 で定義すると、ファイル I/O とファイルシステム操作に 関連する 32 ビット版の関数とデータタイプは自動的に 64 ビット版に
.\" commit 498afc54dfee41d33ba519f496e96480badace8e
.\" commit acd7f096d79c181866d56d4aaf3b043e741f1e2c
.\" commit ade40b10ff5fa59a318cf55b9d8414b758e8df78
-Since glibc 2.20, this macro is deprecated. It now has the same effect as
-defining \fB_DEFAULT_SOURCE\fP, but generates a compile\-time warning (unless
-\fB_DEFAULT_SOURCE\fP is also defined). Use \fB_DEFAULT_SOURCE\fP instead. To
-allow code that requires \fB_BSD_SOURCE\fP in glibc 2.19 and earlier and
-\fB_DEFAULT_SOURCE\fP in glibc 2.20 and later to compile without warnings,
-define \fIboth\fP \fB_BSD_SOURCE\fP and \fB_DEFAULT_SOURCE\fP.
+glibc 2.20 以降では、このマクロは非推奨である。 このマクロは現在は \fB_DEFAULT_SOURCE\fP を定義するのと同じ効果を持つが、
+(\fB_DEFAULT_SOURCE\fP が合わせて定義されていない場合には) コンパイル時の警告が出る。 代わりに \fB_DEFAULT_SOURCE\fP
+を使用すること。 glibc 2.19 以前で \fB_BSD_SOURCE\fP が必要で glibc 2.20 以降で
+\fB_DEFAULT_SOURCE\fP を必要とするプログラムを警告を出さずにコンパイルするには、 \fB_BSD_SOURCE\fP と
+\fB_DEFAULT_SOURCE\fP の\fI両方\fPを定義すること。
.TP
\fB_SVID_SOURCE\fP (glibc 2.20 以降では非推奨)
このマクロを定義すると (値に関わらず) ヘッダファイルで System V 由来の定義が公開される (SVID == System V
Interface Definition; \fBstandards\fP(7) 参照)。
-Since glibc 2.20, this macro is deprecated in the same fashion as
-\fB_BSD_SOURCE\fP.
+glibc 2.20 以降、 \fB_BSD_SOURCE\fP と同様にこのマクロは非推奨となっている。
.TP
\fB_DEFAULT_SOURCE\fP (glibc 2.19 以降)
-This macro can be defined to ensure that the "default" definitions are
-provided even when the defaults would otherwise be disabled, as happens when
-individual macros are explicitly defined, or the compiler is invoked in one
-of its "standard" modes (e.g., \fIcc\ \-std=c99\fP). Defining
-\fB_DEFAULT_SOURCE\fP without defining other individual macros or invoking the
-compiler in one of its "standard" modes has no effect.
-
-The "default" definitions comprise those required by POSIX.1\-2008 as well as
-various definitions derived from BSD and System V. On glibc 2.19 and
-earlier, these defaults were approximately equivalent to explicitly defining
-the following:
+このマクロを使うと、「デフォルト」が無効になるような場合でも「デフォルト」の定義が提供されるようにすることができる。「デフォルト」が無効になるような状況は、個別のマクロが明示的に定義された場合や、コンパイラが「標準」モードのいずれか
+(例えば \fIcc\ \-std=c99\fP)
+で起動された場合などである。他の個々のマクロが定義されず、コンパイラも「標準」モードのいずれかを指定して起動されていない場合は、
+\fB_DEFAULT_SOURCE\fP を定義しても何の効果もない。
+
+「デフォルト」定義は、 POSIX.1\-2008 で必須となっている定義と、 BSD と System V 由来の種々の定義を公開する。 glibc
+2.19 以前では、これらのデフォルトは以下を明示的に定義するのとほぼ等価である。
cc \-D_BSD_SOURCE \-D_SVID_SOURCE \-D_POSIX_C_SOURCE=200809
関連項目のリストに長いマニュアルページ名が多く含まれる場合には、出力を見やすくするために \fI.ad l\fP (右揃えをしない) や \fI.nh\fP
(ハイフンによる折り返しをしない) を活用するとよい。個々のページ名のハイフンによる折り返しは、単語の前に "\e%" を付けることで防ぐことができる。
.SH スタイルガイド
-The following subsections describe the preferred style for the \fIman\-pages\fP
-project. For details not covered below, the Chicago Manual of Style is
-usually a good source; try also grepping for preexisting usage in the
-project source tree.
-.SS "Use of gender\-neutral language"
-As far as possible, use gender\-neutral language in the text of man pages.
-Use of "they" ("them", "themself", "their") as a gender\-neutral singular
-pronoun is acceptable.
+以下の節では\fIman\-pages\fPプロジェクトで推奨のスタイルについて説明している。 ここで触れられていない点については、"the Chicago
+Manual of Style" がたいていはよい情報源になるだろう。
+また、すでに使用されているスタイルについてはプロジェクトのソースツリーを検索してみてほしい。
+(訳注：この章では英語の原文でのスタイルについて説明しており、日本語マニュアルにはあわない点もあるため、具体例などは英語のままとしている箇所もあります。)
+.SS 性別の区別のない表現の使用
+可能な限り、マニュアルページの文章では性別の区別のない表現を使用すること。 性別に区別のない単数形の代名詞として "they" ("them",
+"themself", "their") を使用してもよい。
.SS フォントの慣習
.PP
関数に対しては、引き数には常にイタリック体を用いる。 「たとえ書式 (SYNOPSIS) セクションであっても、このルールに従う」
.fi
(相互参照にセクション番号を含めておくと、 \fBman2html\fP といったツールがページ間のハイパーリンクを適切に生成できる。)
-Control characters should be written in bold face, with no quotes; for
-example, \fB^X\fP.
+制御文字は太字で引用符なしで表記すること。 例えば \fB^X\fP。
.SS "綴り (spelling)"
リリース 2.59 からだが、 \fIman\-pages\fP はアメリカ英語の綴りの慣習に従っている
(以前はイギリス英語とアメリカ英語が基準もなく混在して使われていた)。 新しいページやパッチは全てこの慣習に従って下さい。
-Aside from the well\-known spelling differences, there are a few other
-subtleties to watch for:
+よく知られた綴りの違い以外に、微妙な違いもいくつか見られる。
.IP * 3
-American English tends to use the forms "backward", "upward", "toward", and
-so on rather than the British forms "backwards", "upwards", "towards", and
-so on.
-.SS "BSD version numbers"
-The classical scheme for writing BSD version numbers is \fIx.yBSD\fP, where
-\fIx.y\fP is the version number (e.g., 4.2BSD). Avoid forms such as \fIBSD
-4.3\fP.
+アメリカ英語では "backward", "upward", "toward" を使う傾向にあるが、イギリス英語では "backwards",
+"upwards", "towards" などを使う方が多い。
+.SS "BSD バージョン番号"
+BSD バージョン番号の伝統的な表記方法は \fIx.yBSD\fP である (\fIx.y\fP はバージョン番号; 例: 4.2BSD)。 \fIBSD 4.3\fP
+といった表記は避けること。
.SS 大文字表記
サブセクション ("SS") 見出しでは、最初の単語だけ先頭文字を大文字にし、残りの単語は小文字にすること。但し、英語の用法 (例えば、固有名詞)
やプログラミング言語の要件 (例えば、識別子の名前) などで別の表記をする場合はこの限りではない。
.SS 構造体の定義、シェルのセッションログなどの字下げ、など
構造体の定義やシェルのセッションログなどを本文中に記載する際は、 スペース 4個分の字下げを行う (つまり、ブロックを \fI.in\ +4n\fP と
\&\fI.in\fP で囲む)。
-.SS "Preferred terms"
-The following table lists some preferred terms to use in man pages, mainly
-to ensure consistency across pages.
+.SS 推奨用語
+以下の表にマニュアルページでの使用が推奨される用語を示す。これらは主にマニュアルページ間での一貫性を保つためである。
.TS
l l l
---
zeros zeroes
.TE
.PP
-See also the discussion \fIHyphenation of attributive compounds\fP below.
-.SS "Terms to avoid"
-The following table lists some terms to avoid using in man pages, along with
-some suggested alternatives, mainly to ensure consistency across pages.
+以下の\fI修飾子としての複合語におけるハイフン\fPの議論も参照。
+.SS 使用を避ける用語
+以下の表にマニュアルページでの使用を避けるべき用語を示す。 推奨される表現も合わせて記載している。
+これらは主にマニュアルページ間での一貫性を保つためである。
.TS
l l l
---
l l l.
-Avoid Use instead Notes
+使用を避ける 使用を推奨 備考
32bit 32\-bit T{
-same for 8\-bit, 16\-bit, etc.
+8\-bit, 16\-bit なども同様
T}
current process calling process T{
-A common mistake made by kernel programmers when writing man pages
+カーネルプログラマーがマニュアルページを書く際によくする間違い
T}
manpage T{
man page, manual page
Unixes UNIX systems
.TE
.SS 商標
-Use the correct spelling and case for trademarks. The following is a list
-of the correct spellings of various relevant trademarks that are sometimes
-misspelled:
+商標については正しい綴りと大文字小文字を使うこと。以下は時々綴りの間違いがある商標の正しい綴りのリストである。
DG/UX
HP\-UX
UNIX
UnixWare
-.SS "NULL, NUL, null pointer, and null character"
-A \fInull pointer\fP is a pointer that points to nothing, and is normally
-indicated by the constant \fINULL\fP. On the other hand, \fINUL\fP is the \fInull
-byte\fP, a byte with the value 0, represented in C via the character constant
-\fI\(aq\e0\(aq\fP.
-
-The preferred term for the pointer is "null pointer" or simply "NULL"; avoid
-writing "NULL pointer".
-
-The preferred term for the byte is "null byte". Avoid writing "NUL", since
-it is too easily confused with "NULL". Avoid also the terms "zero byte" and
-"null character". The byte that terminates a C string should be described
-as "the terminating null byte"; strings may be described as
-"null\-terminated", but avoid the use of "NUL\-terminated".
+.SS "NULL, NUL, ヌルポインター、ヌル文字"
+\fInull pointer\fP (\fIヌルポインター\fP) は何もないものを指すポインターで、通常は定数 \fINULL\fP で示される。 一方、
+\fINUL\fP は \fInull byte\fP (\fIヌルバイト\fP、値 0 のバイト) で、 C では文字定数 \fI\(aq\e0\(aq\fP と表現される。
+
+ポインターとして推奨される用語は "null pointer" (ヌルポインター) もしくは単に "NULL" である。 "NULL pointer"
+と記載するのは避けること。
+
+バイトとして推奨される用語は "null byte" (ヌルバイト) である。 "NUL" と記載するのは避けること。 "NUL" は "NULL"
+と間違われることが非常に多いからである。 また、 "zero byte" (ゼロバイト) と "null character" (ヌル文字)
+も避けること。 C の文字列を終端するバイトは "the terminating null byte" (終端ヌルバイト)、
+文字列の説明として使う場合には "null\-terminated" (ヌル終端された) と記載すべきである。 "NUL\-terminated"
+の使用は避けること。
.SS ハイパーリンク
-For hyperlinks, use the \fI.UR\fP/\fI.UE\fP macro pair (see \fBgroff_man\fP(7)).
-This produces proper hyperlinks that can be used in a web browser, when
-rendering a page with, say:
+ハイパーリンクについては、 \fI.UR\fP/\fI.UE\fP マクロの組を使うこと (\fBgroff_man\fP(7)
+参照)。ページを以下のようにレンダリングする場合に、このマクロはウェブブラウザーで使用できる正しいハイパーリンクを生成してくれる。
BROWSER=firefox man \-H pagename
-.SS "Use of e.g., i.e., etc., a.k.a., and similar"
-In general, the use of abbreviations such as "e.g.", "i.e.", "etc.",
-"a.k.a." should be avoided, in favor of suitable full wordings ("for
-example", "that is", "and so on", "also known as").
-
-The only place where such abbreviations may be acceptable is in \fIshort\fP
-parenthetical asides (e.g., like this one).
-
-Always include periods in such abbreviations, as shown here. In addition,
-"e.g." and "i.e." should always be followed by a comma.
-.SS Em\-dashes
-The way to write an em\-dash\(emthe glyph that appears at either end of this
-subphrase\(emin *roff is with the macro "\e(em". (On an ASCII terminal, an
-em\-dash typically renders as two hyphens, but in other typographical
-contexts it renders as a long dash.) Em\-dashes should be written \fIwithout\fP
-surrounding spaces.
-.SS "Hyphenation of attributive compounds"
-Compound terms should be hyphenated when used attributively (i.e., to
-qualify a following noun). Some examples:
-
- 32\-bit value
- command\-line argument
- floating\-point number
- run\-time check
- user\-space function
- wide\-character string
-.SS "Hyphenation with multi, non, pre, re, sub, and so on"
-The general tendency in modern English is not to hyphenate after prefixes
-such as "multi", "non", "pre", "re", "sub", and so on. Manual pages should
-generally follow this rule when these prefixes are used in natural English
-constructions with simple suffixes. The following list gives some examples
-of the preferred forms:
+.SS "e.g., i.e., etc., a.k.a. などの使用"
+一般的には、 "e.g.", "i.e.", "etc.", "a.k.a." などの省略形の使用は避けるべきである。 代わりに完全な形の単語を使うこと
+("for example" (例えば), "that is" (つまり), "and so on" (〜など), "also known as"
+(別名))。
+
+これらの省略形の使用が認められる唯一の場所は、 \fI短い\fP括弧で囲まれた余談 ("(e.g., like this one)") の場合である。
+
+ここで記載しているように、これらの省略形では必ずピリオドを入れること。 また、"e.g." と "i.e." では常に後にカンマも付けること。
+.SS "em によるダッシュ"
+*roff で em によるダッシュ\(emこの部分の両端にある記号\(emを書くには "\e(em" を使う。 (ASCII 端末では em
+によるダッシュは通常ハイフン 2 つとして表示されるが、別の活版印刷の場合などでは長いダッシュとして表示されることもある。) em
+によるダッシュの両側にはスペースを\fI置かないこと\fP。
+.SS 修飾子としての複合語におけるハイフン
+何かを修飾する際 (すなわち後続の名詞を限定する場合) 複合語にはハイフンを入れること。いくつか例を挙げる。
+
+ 32\-bit value (32 ビット値)
+ command\-line argument (コマンドライン引き数)
+ floating\-point number (浮動小数点数)
+ run\-time check (実行時チェック)
+ user\-space function (ユーザー空間関数)
+ wide\-character string (ワイド文字の文字列)
+.SS "multi, non, pre, re, sub などとの組み合わせでのハイフン"
+一般的に最近の英語の傾向では、"multi", "non", "pre", "re", "sub" などの接尾辞の後ろにはハイフンを付けない。
+これらの接尾辞が単純な接尾語との普通の英語の組み合わせの場合には、 マニュアルページでは基本的にこのルールに従う。
+以下のリストに推奨される形式での例をいくつか挙げる。
interprocess
multithreaded
subdirectory
subsystem
-Hyphens should be retained when the prefixes are used in nonstandard English
-words, with trademarks, proper nouns, acronyms, or compound terms. Some
-examples:
+接尾語が通常の英単語以外 (商標、固有名詞、頭字語、複合語) と組み合わされる場合は、ハイフンを使うこと。以下に例を挙げる。
non\-ASCII
non\-English
non\-NULL
non\-real\-time
-Finally, note that "re\-create" and "recreate" are two different verbs, and
-the former is probably what you want.
-.SS "Real minus character"
-Where a real minus character is required (e.g., for numbers such as \-1, or
-when writing options that have a leading dash, such as in \fIls\ \-l\fP), use
-the following form in the man page source:
+最後に、"re\-create" と "recreate" は異なる別の動詞である点に注意すること。たいていの場合、使おうと思っているのは前者であろう。
+.SS 本当のマイナス文字
+本当の意味でのマイナス文字が必要な場合は (\-1 といった数字や \fIls\ \-l\fP
+といった先頭にダッシュのオプションを記載する場合など)、マニュアルページの原文では以下の表記を使うこと。
\e\-
-This guideline applies also to code examples.
-.SS "Character constants"
-To produce single quotes that render well in both ASCII and UTF\-8, use the
-following form for character constants in the man page source:
+このガイドラインはサンプルコードの場合にも適用される。
+.SS 文字定数
+ASCII と UTF\-8 の両方で正しくレンダリングされるシングルクォート (一重引用符)
+を生成するには、マニュアルページの原文では以下の表記を使うこと。
\e(aqC\e(aq
-where \fIC\fP is the quoted character. This guideline applies also to
-character constants used in code examples.
+ここで \fIC\fP が括弧で囲まれる文字である。このガイドラインはサンプルコードの場合にも適用される。
.SS サンプルプログラムとシェルのセッション
マニュアルページには、システムコールやライブラリ関数の使い方を示す サンプルプログラムを含めることができる。 その際には、以下の点に留意すべきである。
.IP * 3
サンプルプログラムは、K&R (Kernighan and Ritchie) スタイルで書き、 字下げはスペース 4文字で行う。 (ソースコードで
TAB 文字を使うのは避けること。)
.IP *
-For consistency, all example programs should terminate using either of:
+一貫性を保つため、すべてのサンプルプログラムは以下のいずれかで終了すること。
exit(EXIT_SUCCESS);
exit(EXIT_FAILURE);
-Avoid using the following forms to terminate a program:
+プログラムを終了するのに以下を使うのは避けること。
exit(0);
exit(1);
return n;
.IP *
-If there is extensive explanatory text before the program source code, mark
-off the source code with a susbsection heading \fIProgram source\fP, as in:
+プログラムソースの前に説明文がある場合は、\fIプログラムソース\fPの見出しをソースコードの前に付けること。
\&.SS プログラムのソース
-Always do this if the explanatory text includes a shell session log.
+説明文がシェルセッションのログを含む場合は必ずこのようにすること。
.PP
プログラムの使い方や他のシステムの特徴を示すためにシェルのセッションログを含める場合、
.IP * 3
各種の標準規格を示すものである。 以下にこれらの標準規格の簡単な説明を記す。
.TP
\fBV7\fP
-Version 7 (also known as Seventh Edition) UNIX, released by AT&T/Bell Labs
-in 1979. After this point, UNIX systems diverged into two main dialects:
-BSD and System V.
+バージョン 7 (第 7 版とも呼ばれる) UNIX。 1979 年に AT&T/Bell Labs によりリリースされた。 この時点以降、 UNIX
+システムは BSD と System V の二つの系譜に分かれた。
.TP
\fB4.2BSD\fP
カリフォルニア大バークレー校 (the University of California at Berkeley) によりリリースされた
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2014-04-24 00:51+0900\n"
-"PO-Revision-Date: 2014-04-24 04:13+0900\n"
+"PO-Revision-Date: 2014-04-27 06:08+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"greater than or equal to 500. New programs should not employ this macro; "
"defining B<_XOPEN_SOURCE> as just described or defining B<_FILE_OFFSET_BITS> "
"with the value 64 is the preferred mechanism to achieve the same result."
-msgstr ""
+msgstr "このマクロは、歴史的には、ファイルオフセットで I<long int> を使う以前の API (B<fseek>(3) や B<ftell>(3)) の制限を解決する関数 (特に B<fseeko>(3) と B<ftello>(3)) を公開するのに使われていた。 このマクロは B<_XOPEN_SOURCE> が 500 以上の値で定義されている場合に暗黙のうちに定義される。 新しいプログラムでぇあこのマクロは使用すべきではない。 B<_XOPEN_SOURCE> をただ定義するか、 B<_FILE_OFFSET_BITS> を値 64 で定義するのが、同じ結果を得るための推奨される方法である。"
#. type: TP
#: build/C/man7/feature_test_macros.7:307
"allow code that requires B<_BSD_SOURCE> in glibc 2.19 and earlier and "
"B<_DEFAULT_SOURCE> in glibc 2.20 and later to compile without warnings, "
"define I<both> B<_BSD_SOURCE> and B<_DEFAULT_SOURCE>."
-msgstr ""
+msgstr "glibc 2.20 以降では、このマクロは非推奨である。 このマクロは現在は B<_DEFAULT_SOURCE> を定義するのと同じ効果を持つが、 (B<_DEFAULT_SOURCE> が合わせて定義されていない場合には) コンパイル時の警告が出る。 代わりに B<_DEFAULT_SOURCE> を使用すること。 glibc 2.19 以前で B<_BSD_SOURCE> が必要で glibc 2.20 以降で B<_DEFAULT_SOURCE> を必要とするプログラムを警告を出さずにコンパイルするには、 B<_BSD_SOURCE> と B<_DEFAULT_SOURCE> のI<両方>を定義すること。"
#. type: TP
#: build/C/man7/feature_test_macros.7:362
msgid ""
"Since glibc 2.20, this macro is deprecated in the same fashion as "
"B<_BSD_SOURCE>."
-msgstr ""
+msgstr "glibc 2.20 以降、 B<_BSD_SOURCE> と同様にこのマクロは非推奨となっている。"
#. type: TP
#: build/C/man7/feature_test_macros.7:371
"of its \"standard\" modes (e.g., I<cc\\ -std=c99>). Defining "
"B<_DEFAULT_SOURCE> without defining other individual macros or invoking the "
"compiler in one of its \"standard\" modes has no effect."
-msgstr ""
+msgstr "このマクロを使うと、「デフォルト」が無効になるような場合でも「デフォルト」の定義が提供されるようにすることができる。「デフォルト」が無効になるような状況は、個別のマクロが明示的に定義された場合や、コンパイラが「標準」モードのいずれか (例えば I<cc\\ -std=c99>) で起動された場合などである。他の個々のマクロが定義されず、コンパイラも「標準」モードのいずれかを指定して起動されていない場合は、 B<_DEFAULT_SOURCE> を定義しても何の効果もない。"
#. type: Plain text
#: build/C/man7/feature_test_macros.7:388
"as various definitions derived from BSD and System V. On glibc 2.19 and "
"earlier, these defaults were approximately equivalent to explicitly defining "
"the following:"
-msgstr ""
+msgstr "「デフォルト」定義は、 POSIX.1-2008 で必須となっている定義と、 BSD と System V 由来の種々の定義を公開する。 glibc 2.19 以前では、これらのデフォルトは以下を明示的に定義するのとほぼ等価である。"
#. type: Plain text
#: build/C/man7/feature_test_macros.7:390
#. type: Plain text
#: build/C/man2/intro.2:44
msgid "In many cases, the C library wrapper function does nothing more than:"
-msgstr ""
+msgstr "多くの場合、 C ライブラリのラッパー関数が行うのは以下のことだけである。"
#. type: Plain text
#: build/C/man2/intro.2:47
msgid ""
"copying arguments and the unique system call number to the registers where "
"the kernel expects them;"
-msgstr ""
+msgstr "引き数と一意なシステムコール番号をカーネルが期待するレジスターにコピーする"
#. type: Plain text
#: build/C/man2/intro.2:50
msgid ""
"trapping to kernel mode, at which point the kernel does the real work of the "
"system call; and"
-msgstr ""
+msgstr "カーネルがシステムコールの実際の処理を行う時点でカーネルモードに入る"
#. type: Plain text
#: build/C/man2/intro.2:55
msgid ""
"setting I<errno> if the system call returns an error number when the kernel "
"returns the CPU to user mode."
-msgstr ""
+msgstr "カーネルが CPU をユーザーモードに返した際にシステムコールがエラー番号を返したいれば I<errno> を設定する"
#. type: Plain text
#: build/C/man2/intro.2:65
"interface and the raw system call. Most commonly, the main DESCRIPTION will "
"focus on the C library interface, and differences for the system call are "
"covered in the NOTES section."
-msgstr ""
+msgstr "しかし、ラッパー関数がこれ以上のことを行う場合もいくつかある。例えば、カーネルモードに入る前に引き数に対する前処理を実行したり、システムコールが返した値に対する後処理を行うなどである。このような場合、セクション 2 のマニュアルページでは、基本的に、C ライブラリ API インターフェース (通常は GNU C ライブラリのもの) と生のシステムコールの両方の詳細をできるだけ説明しようとする。ほとんどの場合、メインとなる「説明」では C ライブラリのインターフェースに焦点をあてて説明し、システムコールでの差分については「注意」のセクションに説明がある。"
#. type: Plain text
#: build/C/man2/intro.2:68
"project. For details not covered below, the Chicago Manual of Style is "
"usually a good source; try also grepping for preexisting usage in the "
"project source tree."
-msgstr ""
+msgstr "以下の節ではI<man-pages>プロジェクトで推奨のスタイルについて説明している。 ここで触れられていない点については、\"the Chicago Manual of Style\" がたいていはよい情報源になるだろう。 また、すでに使用されているスタイルについてはプロジェクトのソースツリーを検索してみてほしい。 (訳注：この章では英語の原文でのスタイルについて説明しており、日本語マニュアルにはあわない点もあるため、具体例などは英語のままとしている箇所もあります。)"
#. type: SS
#: build/C/man7/man-pages.7:466
#, no-wrap
msgid "Use of gender-neutral language"
-msgstr ""
+msgstr "性別の区別のない表現の使用"
#. type: Plain text
#: build/C/man7/man-pages.7:471
"As far as possible, use gender-neutral language in the text of man pages. "
"Use of \"they\" (\"them\", \"themself\", \"their\") as a gender-neutral "
"singular pronoun is acceptable."
-msgstr ""
+msgstr "可能な限り、マニュアルページの文章では性別の区別のない表現を使用すること。 性別に区別のない単数形の代名詞として \"they\" (\"them\", \"themself\", \"their\") を使用してもよい。"
#. type: SS
#: build/C/man7/man-pages.7:471
msgid ""
"Control characters should be written in bold face, with no quotes; for "
"example, B<^X>."
-msgstr ""
+msgstr "制御文字は太字で引用符なしで表記すること。 例えば B<^X>。"
#. type: SS
#: build/C/man7/man-pages.7:561
msgid ""
"Aside from the well-known spelling differences, there are a few other "
"subtleties to watch for:"
-msgstr ""
+msgstr "よく知られた綴りの違い以外に、微妙な違いもいくつか見られる。"
#. type: Plain text
#: build/C/man7/man-pages.7:574
"American English tends to use the forms \"backward\", \"upward\", \"toward"
"\", and so on rather than the British forms \"backwards\", \"upwards\", "
"\"towards\", and so on."
-msgstr ""
+msgstr "アメリカ英語では \"backward\", \"upward\", \"toward\" を使う傾向にあるが、イギリス英語では \"backwards\", \"upwards\", \"towards\" などを使う方が多い。"
#. type: SS
#: build/C/man7/man-pages.7:574
#, no-wrap
msgid "BSD version numbers"
-msgstr ""
+msgstr "BSD バージョン番号"
#. type: Plain text
#: build/C/man7/man-pages.7:582
msgid ""
"The classical scheme for writing BSD version numbers is I<x.yBSD>, where I<x."
"y> is the version number (e.g., 4.2BSD). Avoid forms such as I<BSD 4.3>."
-msgstr ""
+msgstr "BSD バージョン番号の伝統的な表記方法は I<x.yBSD> である (I<x.y> はバージョン番号; 例: 4.2BSD)。 I<BSD 4.3> といった表記は避けること。"
#. type: SS
#: build/C/man7/man-pages.7:582
#: build/C/man7/man-pages.7:597
#, no-wrap
msgid "Preferred terms"
-msgstr ""
+msgstr "推奨用語"
#. type: Plain text
#: build/C/man7/man-pages.7:600
msgid ""
"The following table lists some preferred terms to use in man pages, mainly "
"to ensure consistency across pages."
-msgstr ""
+msgstr "以下の表にマニュアルページでの使用が推奨される用語を示す。これらは主にマニュアルページ間での一貫性を保つためである。"
#. type: tbl table
#: build/C/man7/man-pages.7:604
#. type: Plain text
#: build/C/man7/man-pages.7:657
msgid "See also the discussion I<Hyphenation of attributive compounds> below."
-msgstr ""
+msgstr "以下のI<修飾子としての複合語におけるハイフン>の議論も参照。"
#. type: SS
#: build/C/man7/man-pages.7:657
#, no-wrap
msgid "Terms to avoid"
-msgstr ""
+msgstr "使用を避ける用語"
#. type: Plain text
#: build/C/man7/man-pages.7:661
msgid ""
"The following table lists some terms to avoid using in man pages, along with "
"some suggested alternatives, mainly to ensure consistency across pages."
-msgstr ""
+msgstr "以下の表にマニュアルページでの使用を避けるべき用語を示す。 推奨される表現も合わせて記載している。 これらは主にマニュアルページ間での一貫性を保つためである。"
#. type: tbl table
#: build/C/man7/man-pages.7:665
#, no-wrap
msgid "Avoid\tUse instead\tNotes\n"
-msgstr ""
+msgstr "使用を避ける\t使用を推奨\t備考\n"
#. type: tbl table
#: build/C/man7/man-pages.7:667
#: build/C/man7/man-pages.7:668
#, no-wrap
msgid "same for 8-bit, 16-bit, etc.\n"
-msgstr "same for 8-bit, 16-bit, etc.\n"
+msgstr "8-bit, 16-bit なども同様\n"
#. type: tbl table
#: build/C/man7/man-pages.7:670
#: build/C/man7/man-pages.7:671
#, no-wrap
msgid "A common mistake made by kernel programmers when writing man pages\n"
-msgstr ""
+msgstr "カーネルプログラマーがマニュアルページを書く際によくする間違い\n"
#. type: tbl table
#: build/C/man7/man-pages.7:673
"Use the correct spelling and case for trademarks. The following is a list "
"of the correct spellings of various relevant trademarks that are sometimes "
"misspelled:"
-msgstr ""
+msgstr "商標については正しい綴りと大文字小文字を使うこと。以下は時々綴りの間違いがある商標の正しい綴りのリストである。"
#. type: Plain text
#: build/C/man7/man-pages.7:696
#: build/C/man7/man-pages.7:696
#, no-wrap
msgid "NULL, NUL, null pointer, and null character"
-msgstr ""
+msgstr "NULL, NUL, ヌルポインター、ヌル文字"
#. type: Plain text
#: build/C/man7/man-pages.7:708
"indicated by the constant I<NULL>. On the other hand, I<NUL> is the I<null "
"byte>, a byte with the value 0, represented in C via the character constant "
"I<\\(aq\\e0\\(aq>."
-msgstr ""
+msgstr "I<null pointer> (I<ヌルポインター>) は何もないものを指すポインターで、通常は定数 I<NULL> で示される。 一方、 I<NUL> は I<null byte> (I<ヌルバイト>、値 0 のバイト) で、 C では文字定数 I<\\(aq\\e0\\(aq> と表現される。"
#. type: Plain text
#: build/C/man7/man-pages.7:711
msgid ""
"The preferred term for the pointer is \"null pointer\" or simply \"NULL\"; "
"avoid writing \"NULL pointer\"."
-msgstr ""
+msgstr "ポインターとして推奨される用語は \"null pointer\" (ヌルポインター) もしくは単に \"NULL\" である。 \"NULL pointer\" と記載するのは避けること。"
#. type: Plain text
#: build/C/man7/man-pages.7:719
"byte\" and \"null character\". The byte that terminates a C string should "
"be described as \"the terminating null byte\"; strings may be described as "
"\"null-terminated\", but avoid the use of \"NUL-terminated\"."
-msgstr ""
+msgstr "バイトとして推奨される用語は \"null byte\" (ヌルバイト) である。 \"NUL\" と記載するのは避けること。 \"NUL\" は \"NULL\" と間違われることが非常に多いからである。 また、 \"zero byte\" (ゼロバイト) と \"null character\" (ヌル文字) も避けること。 C の文字列を終端するバイトは \"the terminating null byte\" (終端ヌルバイト)、 文字列の説明として使う場合には \"null-terminated\" (ヌル終端された) と記載すべきである。 \"NUL-terminated\" の使用は避けること。"
#. type: SS
#: build/C/man7/man-pages.7:719
"For hyperlinks, use the I<.UR>/I<.UE> macro pair (see B<groff_man>(7)). "
"This produces proper hyperlinks that can be used in a web browser, when "
"rendering a page with, say:"
-msgstr ""
+msgstr "ハイパーリンクについては、 I<.UR>/I<.UE> マクロの組を使うこと (B<groff_man>(7) 参照)。ページを以下のようにレンダリングする場合に、このマクロはウェブブラウザーで使用できる正しいハイパーリンクを生成してくれる。"
#. type: Plain text
#: build/C/man7/man-pages.7:729
#, no-wrap
msgid " BROWSER=firefox man -H pagename\n"
-msgstr ""
+msgstr " BROWSER=firefox man -H pagename\n"
#. type: SS
#: build/C/man7/man-pages.7:729
#, no-wrap
msgid "Use of e.g., i.e., etc., a.k.a., and similar"
-msgstr ""
+msgstr "e.g., i.e., etc., a.k.a. などの使用"
#. type: Plain text
#: build/C/man7/man-pages.7:733
"In general, the use of abbreviations such as \"e.g.\", \"i.e.\", \"etc.\", "
"\"a.k.a.\" should be avoided, in favor of suitable full wordings (\"for "
"example\", \"that is\", \"and so on\", \"also known as\")."
-msgstr ""
+msgstr "一般的には、 \"e.g.\", \"i.e.\", \"etc.\", \"a.k.a.\" などの省略形の使用は避けるべきである。 代わりに完全な形の単語を使うこと (\"for example\" (例えば), \"that is\" (つまり), \"and so on\" (〜など), \"also known as\" (別名))。"
#. type: Plain text
#: build/C/man7/man-pages.7:737
msgid ""
"The only place where such abbreviations may be acceptable is in I<short> "
"parenthetical asides (e.g., like this one)."
-msgstr ""
+msgstr "これらの省略形の使用が認められる唯一の場所は、 I<短い>括弧で囲まれた余談 (\"(e.g., like this one)\") の場合である。"
#. type: Plain text
#: build/C/man7/man-pages.7:740
msgid ""
"Always include periods in such abbreviations, as shown here. In addition, "
"\"e.g.\" and \"i.e.\" should always be followed by a comma."
-msgstr ""
+msgstr "ここで記載しているように、これらの省略形では必ずピリオドを入れること。 また、\"e.g.\" と \"i.e.\" では常に後にカンマも付けること。"
#. type: SS
#: build/C/man7/man-pages.7:740
#, no-wrap
msgid "Em-dashes"
-msgstr ""
+msgstr "em によるダッシュ"
#. type: Plain text
#: build/C/man7/man-pages.7:748
"an em-dash typically renders as two hyphens, but in other typographical "
"contexts it renders as a long dash.) Em-dashes should be written I<without> "
"surrounding spaces."
-msgstr ""
+msgstr "*roff で em によるダッシュ\\(emこの部分の両端にある記号\\(emを書くには \"\\e(em\" を使う。 (ASCII 端末では em によるダッシュは通常ハイフン 2 つとして表示されるが、別の活版印刷の場合などでは長いダッシュとして表示されることもある。) em によるダッシュの両側にはスペースをI<置かないこと>。"
#. type: SS
#: build/C/man7/man-pages.7:748
#, no-wrap
msgid "Hyphenation of attributive compounds"
-msgstr ""
+msgstr "修飾子としての複合語におけるハイフン"
#. type: Plain text
#: build/C/man7/man-pages.7:751
msgid ""
"Compound terms should be hyphenated when used attributively (i.e., to "
"qualify a following noun). Some examples:"
-msgstr ""
+msgstr "何かを修飾する際 (すなわち後続の名詞を限定する場合) 複合語にはハイフンを入れること。いくつか例を挙げる。"
#. type: Plain text
#: build/C/man7/man-pages.7:758
" user-space function\n"
" wide-character string\n"
msgstr ""
+" 32-bit value (32 ビット値)\n"
+" command-line argument (コマンドライン引き数)\n"
+" floating-point number (浮動小数点数)\n"
+" run-time check (実行時チェック)\n"
+" user-space function (ユーザー空間関数)\n"
+" wide-character string (ワイド文字の文字列)\n"
#. type: SS
#: build/C/man7/man-pages.7:758
#, no-wrap
msgid "Hyphenation with multi, non, pre, re, sub, and so on"
-msgstr ""
+msgstr "multi, non, pre, re, sub などとの組み合わせでのハイフン"
#. type: Plain text
#: build/C/man7/man-pages.7:764
"pages should generally follow this rule when these prefixes are used in "
"natural English constructions with simple suffixes. The following list "
"gives some examples of the preferred forms:"
-msgstr ""
+msgstr "一般的に最近の英語の傾向では、\"multi\", \"non\", \"pre\", \"re\", \"sub\" などの接尾辞の後ろにはハイフンを付けない。 これらの接尾辞が単純な接尾語との普通の英語の組み合わせの場合には、 マニュアルページでは基本的にこのルールに従う。 以下のリストに推奨される形式での例をいくつか挙げる。"
#. type: Plain text
#: build/C/man7/man-pages.7:785
" subdirectory\n"
" subsystem\n"
msgstr ""
+" interprocess\n"
+" multithreaded\n"
+" multiprocess\n"
+" nonblocking\n"
+" nondefault\n"
+" nonempty\n"
+" noninteractive\n"
+" nonnegative\n"
+" nonportable\n"
+" nonzero\n"
+" preallocated\n"
+" precreate\n"
+" prerecorded\n"
+" reestablished\n"
+" reinitialize\n"
+" rearm\n"
+" reread\n"
+" subcomponent\n"
+" subdirectory\n"
+" subsystem\n"
#. type: Plain text
#: build/C/man7/man-pages.7:789
"Hyphens should be retained when the prefixes are used in nonstandard English "
"words, with trademarks, proper nouns, acronyms, or compound terms. Some "
"examples:"
-msgstr ""
+msgstr "接尾語が通常の英単語以外 (商標、固有名詞、頭字語、複合語) と組み合わされる場合は、ハイフンを使うこと。以下に例を挙げる。"
#. type: Plain text
#: build/C/man7/man-pages.7:794
" non-NULL\n"
" non-real-time\n"
msgstr ""
+" non-ASCII\n"
+" non-English\n"
+" non-NULL\n"
+" non-real-time\n"
#. type: Plain text
#: build/C/man7/man-pages.7:797
msgid ""
"Finally, note that \"re-create\" and \"recreate\" are two different verbs, "
"and the former is probably what you want."
-msgstr ""
+msgstr "最後に、\"re-create\" と \"recreate\" は異なる別の動詞である点に注意すること。たいていの場合、使おうと思っているのは前者であろう。"
#. type: SS
#: build/C/man7/man-pages.7:797
#, no-wrap
msgid "Real minus character"
-msgstr ""
+msgstr "本当のマイナス文字"
#. type: Plain text
#: build/C/man7/man-pages.7:802
"Where a real minus character is required (e.g., for numbers such as -1, or "
"when writing options that have a leading dash, such as in I<ls\\ -l>), use "
"the following form in the man page source:"
-msgstr ""
+msgstr "本当の意味でのマイナス文字が必要な場合は (-1 といった数字や I<ls\\ -l> といった先頭にダッシュのオプションを記載する場合など)、マニュアルページの原文では以下の表記を使うこと。"
#. type: Plain text
#: build/C/man7/man-pages.7:804
#, no-wrap
msgid " \\e-\n"
-msgstr ""
+msgstr " \\e-\n"
#. type: Plain text
#: build/C/man7/man-pages.7:806
msgid "This guideline applies also to code examples."
-msgstr ""
+msgstr "このガイドラインはサンプルコードの場合にも適用される。"
#. type: SS
#: build/C/man7/man-pages.7:806
#, no-wrap
msgid "Character constants"
-msgstr ""
+msgstr "文字定数"
#. type: Plain text
#: build/C/man7/man-pages.7:809
msgid ""
"To produce single quotes that render well in both ASCII and UTF-8, use the "
"following form for character constants in the man page source:"
-msgstr ""
+msgstr "ASCII と UTF-8 の両方で正しくレンダリングされるシングルクォート (一重引用符) を生成するには、マニュアルページの原文では以下の表記を使うこと。"
#. type: Plain text
#: build/C/man7/man-pages.7:811
#, no-wrap
msgid " \\e(aqC\\e(aq\n"
-msgstr ""
+msgstr " \\e(aqC\\e(aq\n"
#. type: Plain text
#: build/C/man7/man-pages.7:816
msgid ""
"where I<C> is the quoted character. This guideline applies also to "
"character constants used in code examples."
-msgstr ""
+msgstr "ここで I<C> が括弧で囲まれる文字である。このガイドラインはサンプルコードの場合にも適用される。"
#. type: SS
#: build/C/man7/man-pages.7:816
#. type: Plain text
#: build/C/man7/man-pages.7:848
msgid "For consistency, all example programs should terminate using either of:"
-msgstr ""
+msgstr "一貫性を保つため、すべてのサンプルプログラムは以下のいずれかで終了すること。"
#. type: Plain text
#: build/C/man7/man-pages.7:851
#. type: Plain text
#: build/C/man7/man-pages.7:853
msgid "Avoid using the following forms to terminate a program:"
-msgstr ""
+msgstr "プログラムを終了するのに以下を使うのは避けること。"
#. type: Plain text
#: build/C/man7/man-pages.7:857
msgid ""
"If there is extensive explanatory text before the program source code, mark "
"off the source code with a susbsection heading I<Program source>, as in:"
-msgstr ""
+msgstr "プログラムソースの前に説明文がある場合は、I<プログラムソース>の見出しをソースコードの前に付けること。"
#. type: Plain text
#: build/C/man7/man-pages.7:865
#. type: Plain text
#: build/C/man7/man-pages.7:867
msgid "Always do this if the explanatory text includes a shell session log."
-msgstr ""
+msgstr "説明文がシェルセッションのログを含む場合は必ずこのようにすること。"
#. type: Plain text
#: build/C/man7/man-pages.7:870
"Version 7 (also known as Seventh Edition) UNIX, released by AT&T/Bell Labs "
"in 1979. After this point, UNIX systems diverged into two main dialects: "
"BSD and System V."
-msgstr ""
+msgstr "バージョン 7 (第 7 版とも呼ばれる) UNIX。 1979 年に AT&T/Bell Labs によりリリースされた。 この時点以降、 UNIX システムは BSD と System V の二つの系譜に分かれた。"
#. type: TP
#: build/C/man7/standards.7:37
そのラッパー関数がシステムコールを呼び出すのに必要な処理を実行する。 そのため、システムコールを呼び出すのは通常のライブラリ関数を呼び出すのと
同じように見える。
-In many cases, the C library wrapper function does nothing more than:
+多くの場合、 C ライブラリのラッパー関数が行うのは以下のことだけである。
.IP * 3
-copying arguments and the unique system call number to the registers where
-the kernel expects them;
+引き数と一意なシステムコール番号をカーネルが期待するレジスターにコピーする
.IP *
-trapping to kernel mode, at which point the kernel does the real work of the
-system call; and
+カーネルがシステムコールの実際の処理を行う時点でカーネルモードに入る
.IP *
-setting \fIerrno\fP if the system call returns an error number when the kernel
-returns the CPU to user mode.
+カーネルが CPU をユーザーモードに返した際にシステムコールがエラー番号を返したいれば \fIerrno\fP を設定する
.LP
-However, in a few cases, a wrapper function may do rather more than this,
-for example, performing some preprocessing of the arguments of arguments
-before trapping to kernel mode, or postprocessing of values returned by the
-system call. Where this is the case, the manual pages in Section 2
-generally try to note the details of both the (usually GNU) C library API
-interface and the raw system call. Most commonly, the main DESCRIPTION will
-focus on the C library interface, and differences for the system call are
-covered in the NOTES section.
+しかし、ラッパー関数がこれ以上のことを行う場合もいくつかある。例えば、カーネルモードに入る前に引き数に対する前処理を実行したり、システムコールが返した値に対する後処理を行うなどである。このような場合、セクション
+2 のマニュアルページでは、基本的に、C ライブラリ API インターフェース (通常は GNU C ライブラリのもの)
+と生のシステムコールの両方の詳細をできるだけ説明しようとする。ほとんどの場合、メインとなる「説明」では C
+ライブラリのインターフェースに焦点をあてて説明し、システムコールでの差分については「注意」のセクションに説明がある。
Linux のシステムコールのリストについては \fBsyscalls\fP(2) を参照のこと。
.SH 返り値
\fI_FILE_OFFSET_BITS=64\fP を利用すること。
.TP
\fB_LARGEFILE_SOURCE\fP
-This macro was historically used to expose certain functions (specifically
-\fBfseeko\fP(3) and \fBftello\fP(3)) that address limitations of earlier APIs
-(\fBfeek\fP(3) and \fBftell\fP(3)) that use \fIlong int\fP for file offsets. This
-macro is implicitly defined if \fB_XOPEN_SOURCE\fP is defined with a value
-greater than or equal to 500. New programs should not employ this macro;
-defining \fB_XOPEN_SOURCE\fP as just described or defining \fB_FILE_OFFSET_BITS\fP
-with the value 64 is the preferred mechanism to achieve the same result.
+このマクロは、歴史的には、ファイルオフセットで \fIlong int\fP を使う以前の API (\fBfseek\fP(3) や \fBftell\fP(3))
+の制限を解決する関数 (特に \fBfseeko\fP(3) と \fBftello\fP(3)) を公開するのに使われていた。 このマクロは
+\fB_XOPEN_SOURCE\fP が 500 以上の値で定義されている場合に暗黙のうちに定義される。
+新しいプログラムでぇあこのマクロは使用すべきではない。 \fB_XOPEN_SOURCE\fP をただ定義するか、 \fB_FILE_OFFSET_BITS\fP
+を値 64 で定義するのが、同じ結果を得るための推奨される方法である。
.TP
\fB_FILE_OFFSET_BITS\fP
このマクロを値 64 で定義すると、ファイル I/O とファイルシステム操作に 関連する 32 ビット版の関数とデータタイプは自動的に 64 ビット版に
.\" commit 498afc54dfee41d33ba519f496e96480badace8e
.\" commit acd7f096d79c181866d56d4aaf3b043e741f1e2c
.\" commit ade40b10ff5fa59a318cf55b9d8414b758e8df78
-Since glibc 2.20, this macro is deprecated. It now has the same effect as
-defining \fB_DEFAULT_SOURCE\fP, but generates a compile\-time warning (unless
-\fB_DEFAULT_SOURCE\fP is also defined). Use \fB_DEFAULT_SOURCE\fP instead. To
-allow code that requires \fB_BSD_SOURCE\fP in glibc 2.19 and earlier and
-\fB_DEFAULT_SOURCE\fP in glibc 2.20 and later to compile without warnings,
-define \fIboth\fP \fB_BSD_SOURCE\fP and \fB_DEFAULT_SOURCE\fP.
+glibc 2.20 以降では、このマクロは非推奨である。 このマクロは現在は \fB_DEFAULT_SOURCE\fP を定義するのと同じ効果を持つが、
+(\fB_DEFAULT_SOURCE\fP が合わせて定義されていない場合には) コンパイル時の警告が出る。 代わりに \fB_DEFAULT_SOURCE\fP
+を使用すること。 glibc 2.19 以前で \fB_BSD_SOURCE\fP が必要で glibc 2.20 以降で
+\fB_DEFAULT_SOURCE\fP を必要とするプログラムを警告を出さずにコンパイルするには、 \fB_BSD_SOURCE\fP と
+\fB_DEFAULT_SOURCE\fP の\fI両方\fPを定義すること。
.TP
\fB_SVID_SOURCE\fP (glibc 2.20 以降では非推奨)
このマクロを定義すると (値に関わらず) ヘッダファイルで System V 由来の定義が公開される (SVID == System V
Interface Definition; \fBstandards\fP(7) 参照)。
-Since glibc 2.20, this macro is deprecated in the same fashion as
-\fB_BSD_SOURCE\fP.
+glibc 2.20 以降、 \fB_BSD_SOURCE\fP と同様にこのマクロは非推奨となっている。
.TP
\fB_DEFAULT_SOURCE\fP (glibc 2.19 以降)
-This macro can be defined to ensure that the "default" definitions are
-provided even when the defaults would otherwise be disabled, as happens when
-individual macros are explicitly defined, or the compiler is invoked in one
-of its "standard" modes (e.g., \fIcc\ \-std=c99\fP). Defining
-\fB_DEFAULT_SOURCE\fP without defining other individual macros or invoking the
-compiler in one of its "standard" modes has no effect.
-
-The "default" definitions comprise those required by POSIX.1\-2008 as well as
-various definitions derived from BSD and System V. On glibc 2.19 and
-earlier, these defaults were approximately equivalent to explicitly defining
-the following:
+このマクロを使うと、「デフォルト」が無効になるような場合でも「デフォルト」の定義が提供されるようにすることができる。「デフォルト」が無効になるような状況は、個別のマクロが明示的に定義された場合や、コンパイラが「標準」モードのいずれか
+(例えば \fIcc\ \-std=c99\fP)
+で起動された場合などである。他の個々のマクロが定義されず、コンパイラも「標準」モードのいずれかを指定して起動されていない場合は、
+\fB_DEFAULT_SOURCE\fP を定義しても何の効果もない。
+
+「デフォルト」定義は、 POSIX.1\-2008 で必須となっている定義と、 BSD と System V 由来の種々の定義を公開する。 glibc
+2.19 以前では、これらのデフォルトは以下を明示的に定義するのとほぼ等価である。
cc \-D_BSD_SOURCE \-D_SVID_SOURCE \-D_POSIX_C_SOURCE=200809
関連項目のリストに長いマニュアルページ名が多く含まれる場合には、出力を見やすくするために \fI.ad l\fP (右揃えをしない) や \fI.nh\fP
(ハイフンによる折り返しをしない) を活用するとよい。個々のページ名のハイフンによる折り返しは、単語の前に "\e%" を付けることで防ぐことができる。
.SH スタイルガイド
-The following subsections describe the preferred style for the \fIman\-pages\fP
-project. For details not covered below, the Chicago Manual of Style is
-usually a good source; try also grepping for preexisting usage in the
-project source tree.
-.SS "Use of gender\-neutral language"
-As far as possible, use gender\-neutral language in the text of man pages.
-Use of "they" ("them", "themself", "their") as a gender\-neutral singular
-pronoun is acceptable.
+以下の節では\fIman\-pages\fPプロジェクトで推奨のスタイルについて説明している。 ここで触れられていない点については、"the Chicago
+Manual of Style" がたいていはよい情報源になるだろう。
+また、すでに使用されているスタイルについてはプロジェクトのソースツリーを検索してみてほしい。
+(訳注：この章では英語の原文でのスタイルについて説明しており、日本語マニュアルにはあわない点もあるため、具体例などは英語のままとしている箇所もあります。)
+.SS 性別の区別のない表現の使用
+可能な限り、マニュアルページの文章では性別の区別のない表現を使用すること。 性別に区別のない単数形の代名詞として "they" ("them",
+"themself", "their") を使用してもよい。
.SS フォントの慣習
.PP
関数に対しては、引き数には常にイタリック体を用いる。 「たとえ書式 (SYNOPSIS) セクションであっても、このルールに従う」
.fi
(相互参照にセクション番号を含めておくと、 \fBman2html\fP といったツールがページ間のハイパーリンクを適切に生成できる。)
-Control characters should be written in bold face, with no quotes; for
-example, \fB^X\fP.
+制御文字は太字で引用符なしで表記すること。 例えば \fB^X\fP。
.SS "綴り (spelling)"
リリース 2.59 からだが、 \fIman\-pages\fP はアメリカ英語の綴りの慣習に従っている
(以前はイギリス英語とアメリカ英語が基準もなく混在して使われていた)。 新しいページやパッチは全てこの慣習に従って下さい。
-Aside from the well\-known spelling differences, there are a few other
-subtleties to watch for:
+よく知られた綴りの違い以外に、微妙な違いもいくつか見られる。
.IP * 3
-American English tends to use the forms "backward", "upward", "toward", and
-so on rather than the British forms "backwards", "upwards", "towards", and
-so on.
-.SS "BSD version numbers"
-The classical scheme for writing BSD version numbers is \fIx.yBSD\fP, where
-\fIx.y\fP is the version number (e.g., 4.2BSD). Avoid forms such as \fIBSD
-4.3\fP.
+アメリカ英語では "backward", "upward", "toward" を使う傾向にあるが、イギリス英語では "backwards",
+"upwards", "towards" などを使う方が多い。
+.SS "BSD バージョン番号"
+BSD バージョン番号の伝統的な表記方法は \fIx.yBSD\fP である (\fIx.y\fP はバージョン番号; 例: 4.2BSD)。 \fIBSD 4.3\fP
+といった表記は避けること。
.SS 大文字表記
サブセクション ("SS") 見出しでは、最初の単語だけ先頭文字を大文字にし、残りの単語は小文字にすること。但し、英語の用法 (例えば、固有名詞)
やプログラミング言語の要件 (例えば、識別子の名前) などで別の表記をする場合はこの限りではない。
.SS 構造体の定義、シェルのセッションログなどの字下げ、など
構造体の定義やシェルのセッションログなどを本文中に記載する際は、 スペース 4個分の字下げを行う (つまり、ブロックを \fI.in\ +4n\fP と
\&\fI.in\fP で囲む)。
-.SS "Preferred terms"
-The following table lists some preferred terms to use in man pages, mainly
-to ensure consistency across pages.
+.SS 推奨用語
+以下の表にマニュアルページでの使用が推奨される用語を示す。これらは主にマニュアルページ間での一貫性を保つためである。
.TS
l l l
---
zeros zeroes
.TE
.PP
-See also the discussion \fIHyphenation of attributive compounds\fP below.
-.SS "Terms to avoid"
-The following table lists some terms to avoid using in man pages, along with
-some suggested alternatives, mainly to ensure consistency across pages.
+以下の\fI修飾子としての複合語におけるハイフン\fPの議論も参照。
+.SS 使用を避ける用語
+以下の表にマニュアルページでの使用を避けるべき用語を示す。 推奨される表現も合わせて記載している。
+これらは主にマニュアルページ間での一貫性を保つためである。
.TS
l l l
---
l l l.
-Avoid Use instead Notes
+使用を避ける 使用を推奨 備考
32bit 32\-bit T{
-same for 8\-bit, 16\-bit, etc.
+8\-bit, 16\-bit なども同様
T}
current process calling process T{
-A common mistake made by kernel programmers when writing man pages
+カーネルプログラマーがマニュアルページを書く際によくする間違い
T}
manpage T{
man page, manual page
Unixes UNIX systems
.TE
.SS 商標
-Use the correct spelling and case for trademarks. The following is a list
-of the correct spellings of various relevant trademarks that are sometimes
-misspelled:
+商標については正しい綴りと大文字小文字を使うこと。以下は時々綴りの間違いがある商標の正しい綴りのリストである。
DG/UX
HP\-UX
UNIX
UnixWare
-.SS "NULL, NUL, null pointer, and null character"
-A \fInull pointer\fP is a pointer that points to nothing, and is normally
-indicated by the constant \fINULL\fP. On the other hand, \fINUL\fP is the \fInull
-byte\fP, a byte with the value 0, represented in C via the character constant
-\fI\(aq\e0\(aq\fP.
-
-The preferred term for the pointer is "null pointer" or simply "NULL"; avoid
-writing "NULL pointer".
-
-The preferred term for the byte is "null byte". Avoid writing "NUL", since
-it is too easily confused with "NULL". Avoid also the terms "zero byte" and
-"null character". The byte that terminates a C string should be described
-as "the terminating null byte"; strings may be described as
-"null\-terminated", but avoid the use of "NUL\-terminated".
+.SS "NULL, NUL, ヌルポインター、ヌル文字"
+\fInull pointer\fP (\fIヌルポインター\fP) は何もないものを指すポインターで、通常は定数 \fINULL\fP で示される。 一方、
+\fINUL\fP は \fInull byte\fP (\fIヌルバイト\fP、値 0 のバイト) で、 C では文字定数 \fI\(aq\e0\(aq\fP と表現される。
+
+ポインターとして推奨される用語は "null pointer" (ヌルポインター) もしくは単に "NULL" である。 "NULL pointer"
+と記載するのは避けること。
+
+バイトとして推奨される用語は "null byte" (ヌルバイト) である。 "NUL" と記載するのは避けること。 "NUL" は "NULL"
+と間違われることが非常に多いからである。 また、 "zero byte" (ゼロバイト) と "null character" (ヌル文字)
+も避けること。 C の文字列を終端するバイトは "the terminating null byte" (終端ヌルバイト)、
+文字列の説明として使う場合には "null\-terminated" (ヌル終端された) と記載すべきである。 "NUL\-terminated"
+の使用は避けること。
.SS ハイパーリンク
-For hyperlinks, use the \fI.UR\fP/\fI.UE\fP macro pair (see \fBgroff_man\fP(7)).
-This produces proper hyperlinks that can be used in a web browser, when
-rendering a page with, say:
+ハイパーリンクについては、 \fI.UR\fP/\fI.UE\fP マクロの組を使うこと (\fBgroff_man\fP(7)
+参照)。ページを以下のようにレンダリングする場合に、このマクロはウェブブラウザーで使用できる正しいハイパーリンクを生成してくれる。
BROWSER=firefox man \-H pagename
-.SS "Use of e.g., i.e., etc., a.k.a., and similar"
-In general, the use of abbreviations such as "e.g.", "i.e.", "etc.",
-"a.k.a." should be avoided, in favor of suitable full wordings ("for
-example", "that is", "and so on", "also known as").
-
-The only place where such abbreviations may be acceptable is in \fIshort\fP
-parenthetical asides (e.g., like this one).
-
-Always include periods in such abbreviations, as shown here. In addition,
-"e.g." and "i.e." should always be followed by a comma.
-.SS Em\-dashes
-The way to write an em\-dash\(emthe glyph that appears at either end of this
-subphrase\(emin *roff is with the macro "\e(em". (On an ASCII terminal, an
-em\-dash typically renders as two hyphens, but in other typographical
-contexts it renders as a long dash.) Em\-dashes should be written \fIwithout\fP
-surrounding spaces.
-.SS "Hyphenation of attributive compounds"
-Compound terms should be hyphenated when used attributively (i.e., to
-qualify a following noun). Some examples:
-
- 32\-bit value
- command\-line argument
- floating\-point number
- run\-time check
- user\-space function
- wide\-character string
-.SS "Hyphenation with multi, non, pre, re, sub, and so on"
-The general tendency in modern English is not to hyphenate after prefixes
-such as "multi", "non", "pre", "re", "sub", and so on. Manual pages should
-generally follow this rule when these prefixes are used in natural English
-constructions with simple suffixes. The following list gives some examples
-of the preferred forms:
+.SS "e.g., i.e., etc., a.k.a. などの使用"
+一般的には、 "e.g.", "i.e.", "etc.", "a.k.a." などの省略形の使用は避けるべきである。 代わりに完全な形の単語を使うこと
+("for example" (例えば), "that is" (つまり), "and so on" (〜など), "also known as"
+(別名))。
+
+これらの省略形の使用が認められる唯一の場所は、 \fI短い\fP括弧で囲まれた余談 ("(e.g., like this one)") の場合である。
+
+ここで記載しているように、これらの省略形では必ずピリオドを入れること。 また、"e.g." と "i.e." では常に後にカンマも付けること。
+.SS "em によるダッシュ"
+*roff で em によるダッシュ\(emこの部分の両端にある記号\(emを書くには "\e(em" を使う。 (ASCII 端末では em
+によるダッシュは通常ハイフン 2 つとして表示されるが、別の活版印刷の場合などでは長いダッシュとして表示されることもある。) em
+によるダッシュの両側にはスペースを\fI置かないこと\fP。
+.SS 修飾子としての複合語におけるハイフン
+何かを修飾する際 (すなわち後続の名詞を限定する場合) 複合語にはハイフンを入れること。いくつか例を挙げる。
+
+ 32\-bit value (32 ビット値)
+ command\-line argument (コマンドライン引き数)
+ floating\-point number (浮動小数点数)
+ run\-time check (実行時チェック)
+ user\-space function (ユーザー空間関数)
+ wide\-character string (ワイド文字の文字列)
+.SS "multi, non, pre, re, sub などとの組み合わせでのハイフン"
+一般的に最近の英語の傾向では、"multi", "non", "pre", "re", "sub" などの接尾辞の後ろにはハイフンを付けない。
+これらの接尾辞が単純な接尾語との普通の英語の組み合わせの場合には、 マニュアルページでは基本的にこのルールに従う。
+以下のリストに推奨される形式での例をいくつか挙げる。
interprocess
multithreaded
subdirectory
subsystem
-Hyphens should be retained when the prefixes are used in nonstandard English
-words, with trademarks, proper nouns, acronyms, or compound terms. Some
-examples:
+接尾語が通常の英単語以外 (商標、固有名詞、頭字語、複合語) と組み合わされる場合は、ハイフンを使うこと。以下に例を挙げる。
non\-ASCII
non\-English
non\-NULL
non\-real\-time
-Finally, note that "re\-create" and "recreate" are two different verbs, and
-the former is probably what you want.
-.SS "Real minus character"
-Where a real minus character is required (e.g., for numbers such as \-1, or
-when writing options that have a leading dash, such as in \fIls\ \-l\fP), use
-the following form in the man page source:
+最後に、"re\-create" と "recreate" は異なる別の動詞である点に注意すること。たいていの場合、使おうと思っているのは前者であろう。
+.SS 本当のマイナス文字
+本当の意味でのマイナス文字が必要な場合は (\-1 といった数字や \fIls\ \-l\fP
+といった先頭にダッシュのオプションを記載する場合など)、マニュアルページの原文では以下の表記を使うこと。
\e\-
-This guideline applies also to code examples.
-.SS "Character constants"
-To produce single quotes that render well in both ASCII and UTF\-8, use the
-following form for character constants in the man page source:
+このガイドラインはサンプルコードの場合にも適用される。
+.SS 文字定数
+ASCII と UTF\-8 の両方で正しくレンダリングされるシングルクォート (一重引用符)
+を生成するには、マニュアルページの原文では以下の表記を使うこと。
\e(aqC\e(aq
-where \fIC\fP is the quoted character. This guideline applies also to
-character constants used in code examples.
+ここで \fIC\fP が括弧で囲まれる文字である。このガイドラインはサンプルコードの場合にも適用される。
.SS サンプルプログラムとシェルのセッション
マニュアルページには、システムコールやライブラリ関数の使い方を示す サンプルプログラムを含めることができる。 その際には、以下の点に留意すべきである。
.IP * 3
サンプルプログラムは、K&R (Kernighan and Ritchie) スタイルで書き、 字下げはスペース 4文字で行う。 (ソースコードで
TAB 文字を使うのは避けること。)
.IP *
-For consistency, all example programs should terminate using either of:
+一貫性を保つため、すべてのサンプルプログラムは以下のいずれかで終了すること。
exit(EXIT_SUCCESS);
exit(EXIT_FAILURE);
-Avoid using the following forms to terminate a program:
+プログラムを終了するのに以下を使うのは避けること。
exit(0);
exit(1);
return n;
.IP *
-If there is extensive explanatory text before the program source code, mark
-off the source code with a susbsection heading \fIProgram source\fP, as in:
+プログラムソースの前に説明文がある場合は、\fIプログラムソース\fPの見出しをソースコードの前に付けること。
\&.SS プログラムのソース
-Always do this if the explanatory text includes a shell session log.
+説明文がシェルセッションのログを含む場合は必ずこのようにすること。
.PP
プログラムの使い方や他のシステムの特徴を示すためにシェルのセッションログを含める場合、
.IP * 3
各種の標準規格を示すものである。 以下にこれらの標準規格の簡単な説明を記す。
.TP
\fBV7\fP
-Version 7 (also known as Seventh Edition) UNIX, released by AT&T/Bell Labs
-in 1979. After this point, UNIX systems diverged into two main dialects:
-BSD and System V.
+バージョン 7 (第 7 版とも呼ばれる) UNIX。 1979 年に AT&T/Bell Labs によりリリースされた。 この時点以降、 UNIX
+システムは BSD と System V の二つの系譜に分かれた。
.TP
\fB4.2BSD\fP
カリフォルニア大バークレー校 (the University of California at Berkeley) によりリリースされた
# pagename,#complete,#remaining,#all
-feature_test_macros.7,163,5,168
-intro.2,27,5,32
-man-pages.7,239,49,288
proc.5,888,78,966
-standards.7,79,1,80
＠:LDP man-pages:3.65:2012/12/31:insb:2:outb:2:
＠:LDP man-pages:3.65:2012/12/31:insl:2:outb:2:
＠:LDP man-pages:3.65:2012/12/31:insw:2:outb:2:
-â\98\86:LDP man-pages:3.54=>3.65:2014/02/20:intro:2:2013/03/25::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.65:2014/02/20:intro:2:2014/04/27::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.65:2012/12/31:inw:2:outb:2:
＠:LDP man-pages:3.65:2012/12/31:inw_p:2:outb:2:
○:LDP man-pages:3.65:2013/04/10:io_cancel:2:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2008/11/20:ddp:7:2014/04/24::nakano@apm.seikei.ac.jp:NAKANO Takeo:
○:LDP man-pages:3.65:2014/01/18:environ:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2012/04/17:epoll:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.54=>3.65:2014/03/20:feature_test_macros:7:2013/09/30::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.65:2014/03/20:feature_test_macros:7:2014/04/27::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2008/12/03:fifo:7:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.65:2012/08/05:futex:7:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.65:2014/04/20:glibc:7:libc:7:
○:LDP man-pages:3.65:2014/03/18:locale:7:2014/04/26::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2004/09/15:mailaddr:7:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.65:2012/08/05:man:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.54=>3.65:2014/03/16:man-pages:7:2013/08/30::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.65:2014/03/16:man-pages:7:2014/04/27::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2008/08/11:math_error:7:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.65:0000/00/00:mdoc:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:0000/00/00:mdoc.samples:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2013/07/30:signal:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.65:2014/02/21:socket:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.65:2007/12/20:spufs:7:::::
-â\98\86:LDP man-pages:3.54=>3.65:2014/01/15:standards:7:2013/10/14::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.65:2014/01/15:standards:7:2014/04/27::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.65:2000/11/16:suffixes:7:2014/04/24::ysato@h4.dion.ne.jp:Yuichi SATO:
○:LDP man-pages:3.65:2013/02/12:svipc:7:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
×:LDP man-pages:3.65:2014/04/06:symlink:7:::::
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>inotify</B></TD></TR>
<TR class="over80"><TD>inotify.7</TD><TD>20/153</TD><TD>86.93</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>intro</B></TD></TR>
-<TR class="over80"><TD>feature_test_macros.7</TD><TD>5/168</TD><TD>97.02</TD></TR>
-<TR class="over80"><TD>intro.2</TD><TD>5/32</TD><TD>84.38</TD></TR>
-<TR class="over80"><TD>man-pages.7</TD><TD>49/288</TD><TD>82.99</TD></TR>
<TR class="over80"><TD>proc.5</TD><TD>78/966</TD><TD>91.93</TD></TR>
-<TR class="over80"><TD>standards.7</TD><TD>1/80</TD><TD>98.75</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>keyutils</B></TD></TR>
<TR><TD>add_key.2</TD><TD>23/53</TD><TD>56.60</TD></TR>
<TR><TD>keyctl.2</TD><TD>31/68</TD><TD>54.41</TD></TR>
<TR class="over70"><TD>futimesat.2</TD><TD>10/37</TD><TD>72.97</TD></TR>
<TR><TD>utimensat.2</TD><TD>49/107</TD><TD>54.21</TD></TR>
<TR class="over80"><TD>zdump.8</TD><TD>1/22</TD><TD>95.45</TD></TR>
-<TR><TD COLSPAN=3>Total 62 pages</TD></TR>
+<TR><TD COLSPAN=3>Total 58 pages</TD></TR>
</TABLE>
</BODY></HTML>
OSDN Git Service
