--- /dev/null
+.\" Copyright (c) 2008, Linux Foundation, written by Michael Kerrisk
+.\" <mtk.manpages@gmail.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH FOPENCOOKIE 3 2015\-01\-22 Linux "Linux Programmer's Manual"
+.SH 名前
+fopencookie \- 独自のストリームをオープンする
+.SH 書式
+.nf
+\fB#define _GNU_SOURCE\fP /* feature_test_macros(7) 参照 */
+\fB#include <stdio.h>\fP
+
+\fBFILE *fopencookie(void *\fP\fIcookie\fP\fB, const char *\fP\fImode\fP\fB,\fP
+\fB cookie_io_functions_t \fP\fIio_funcs\fP\fB);\fP
+.fi
+.SH 説明
+\fBfopencookie\fP() を使うと、 プログラマーは標準 I/O ストリームの独自の実装を作成することができる。
+この実装はストリームのデータを自分が選んだ場所に格納することができる。 例えば、 \fBfopencookie\fP() は \fBfmemopen\fP(3)
+を実装するのに使用されている。 \fBfmemopen\fP(3)
+はメモリー上のバッファーに格納されたデータに対するストリームインターフェースを提供している。
+
+独自のストリームを作成するためには、 プログラマーは以下を行う必要がある。
+.IP * 3
+ストリームに対する I/O を実行する際に標準 I/O ライブラリが内部で使用する 4 つの "フック" 関数を実装する。
+.IP *
+"cookie" データ型を定義する。 "cookie" データ型は、上記のフック関数が使用する管理情報 (例えば、データを格納する場所など)
+を提供する構造体である。 標準の I/O パッケージにはこの cookie の内容に関する情報を持たないが (したがって
+\fBfopencookie\fP() に渡される際の型は \fIvoid\ *\fP である)、 フック関数が呼び出される際に第一引き数として cookie
+が渡される。
+.IP *
+\fBfopencookie\fP() を呼び出して、新しいストリームをオープンし、 そのストリームに cookie とフック関数を関連付ける。
+.PP
+\fBfopencookie\fP() 関数は \fBfopen\fP(3) と同様の機能を持つ。 新しいストリームをオープンし、
+そのストリームに対して操作を行うのに使用する \fIFILE\fP オブジェクトへのポインターを返す。
+
+\fIcookie\fP 引き数は、 新しいストリームに関連付けられる呼び出し元の cookie 構造体へのポインターである。 このポインターは、 標準
+I/O ライブラリが以下で説明するフック関数のいずれかを呼び出す際に第 1 引き数として渡される。
+
+\fImode\fP 引き数は \fBfopen\fP(3) と同じ意味を持つ。 指定できるモードは \fIr\fP, \fIw\fP, \fIa\fP, \fIr+\fP, \fIw+\fP,
+\fIa+\fP である。 詳細は \fBfopen\fP(3) を参照。
+
+\fIio_funcs\fP 引き数は、 このストリームを実装するのに使用されるプログラマーが定義した関数を指す 4 つのフィールドを持つ構造体である。
+この構造体は以下のように定義されている。
+.in +4n
+.nf
+
+typedef struct {
+ cookie_read_function_t *read;
+ cookie_write_function_t *write;
+ cookie_seek_function_t *seek;
+ cookie_close_function_t *close;
+} cookie_io_functions_t;
+
+.fi
+.in
+4 つのフィールドの詳細は以下のとおりである。
+.TP
+\fIcookie_read_function_t *read\fP
+この関数はストリームに対する read 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。
+
+ ssize_t read(void *cookie, char *buf, size_t size);
+
+引き数 \fIbuf\fP と \fIsize\fP は、 それぞれ、 入力データを配置できるバッファーとそのバッファーのサイズである。 関数の結果として、
+\fIread\fP 関数は \fIbuf\fP にコピーされたバイト数を、 ファイル末尾の場合は 0 を、 エラーの場合は \-1 を返す。 \fIread\fP
+関数はストリームのオフセットを適切に更新すべきである。
+
+\fI*read\fP がヌルポインターの場合、 独自のストリームからの読み出しは常にファイル末尾 (end of file) を返す。
+.TP
+\fIcookie_write_function_t *write\fP
+この関数はストリームに対する write 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。
+
+ ssize_t write(void *cookie, const char *buf, size_t size);
+
+引き数 \fIbuf\fP と \fIsize\fP は、 それぞれ、 ストリームへの出力するデータが入ったバッファーとそのバッファーのサイズである。
+関数の結果として、 \fIwrite\fP 関数は \fIbuf\fP からコピーされたバイト数を返し、 エラーの場合は \-1 を返す。
+(この関数は負の値を返してはならない。) \fIwrite\fP 関数はストリームのオフセットを適切に更新すべきである。
+
+\fI*write\fP がヌルポインターの場合、 このストリームへの出力は破棄される。
+.TP
+\fIcookie_seek_function_t *seek\fP
+この関数はストリームに対する seek 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。
+
+ int seek(void *cookie, off64_t *offset, int whence);
+
+\fI*offset\fP 引き数は新しいファイルオフセットを指定する。 新しいオフセットは \fIwhence\fP
+に以下の値のどれが指定されたかに応じて決まる。
+.RS
+.TP 10
+\fBSEEK_SET\fP
+ストリームオフセットを、ストリームの先頭から \fI*offset\fP バイトの位置に設定する。
+.TP
+\fBSEEK_CUR\fP
+ストリームの現在のオフセットに \fI*offset\fP を加算する。
+.TP
+\fBSEEK_END\fP
+ストリームのオフセットを、ストリームのサイズに \fI*offset\fP を足した場所に設定する。
+.RE
+.IP
+関数が返る前に、 \fIseek\fP 関数はストリームの新しいオフセットを示すように \fI*offset\fP を更新すべきである。
+
+関数の結果として、 \fIseek\fP 関数は成功すると 0 を、 エラーの場合 \-1 を返す。
+
+\fI*seek\fP がヌルポインターの場合、 このストリームに対して seek 操作を行うことができない。
+.TP
+\fIcookie_close_function_t *close\fP
+この関数はストリームをクローズする。 このフック関数では、 このストリームに割り当てられたバッファを解放するといったことができる。 呼び出される際、 1
+つの引き数を受け取る。
+
+ int close(void *cookie);
+
+\fIcookie\fP 引き数は \fBfopencookie\fP() の呼び出し時にプログラマーが渡した cookie である。
+
+関数の結果として、 \fIclose\fP 関数は成功すると 0 を、 エラーの場合 \fBEOF\fP を返す。
+
+\fI*close\fP が NULL の場合、 ストリームがクローズされる際に特別な操作は何も行われない。
+.SH 返り値
+.\" .SH ERRORS
+.\" It's not clear if errno ever gets set...
+成功すると \fBfopencookie\fP() は新しいストリームへのポインターを返す。 エラーの場合、 NULL が返される。
+.SH 準拠
+この関数は非標準の GNU 拡張である。
+.SH 例
+以下のプログラムは、 \fBfmemopen\fP(3) で利用できるのと似た (同じではない) 機能を持つ独自のストリームを実装している。
+データがメモリーバッファーに格納されるストリームを実装している。 このプログラムは、 コマンドライン引き数をストリームに書き込み、
+それからストリームをたどって 5 文字ごとに 2 文字を読み出して、 それを標準出力に書き込む。 以下のシェルセッションはこのプログラムの使用例である。
+.in +4n
+.nf
+
+$\fB ./a.out \(aqhello world\(aq\fP
+/he/
+/ w/
+/d/
+Reached end of file
+
+.fi
+.in
+このプログラムを改良して様々なエラー状況に強くすることもできる (例えば、 オープン済みのストリームに対応する cookie
+でストリームをオープンしようとした、 すでにクローズされたストリームをクローズしようとした、など)。
+.SS プログラムのソース
+\&
+.nf
+#define _GNU_SOURCE
+#include <sys/types.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <string.h>
+
+#define INIT_BUF_SIZE 4
+
+struct memfile_cookie {
+ char *buf; /* Dynamically sized buffer for data */
+ size_t allocated; /* Size of buf */
+ size_t endpos; /* Number of characters in buf */
+ off_t offset; /* Current file offset in buf */
+};
+
+ssize_t
+memfile_write(void *c, const char *buf, size_t size)
+{
+ char *new_buff;
+ struct memfile_cookie *cookie = c;
+
+ /* Buffer too small? Keep doubling size until big enough */
+
+ while (size + cookie\->offset > cookie\->allocated) {
+ new_buff = realloc(cookie\->buf, cookie\->allocated * 2);
+ if (new_buff == NULL) {
+ return \-1;
+ } else {
+ cookie\->allocated *= 2;
+ cookie\->buf = new_buff;
+ }
+ }
+
+ memcpy(cookie\->buf + cookie\->offset, buf, size);
+
+ cookie\->offset += size;
+ if (cookie\->offset > cookie\->endpos)
+ cookie\->endpos = cookie\->offset;
+
+ return size;
+}
+
+ssize_t
+memfile_read(void *c, char *buf, size_t size)
+{
+ ssize_t xbytes;
+ struct memfile_cookie *cookie = c;
+
+ /* Fetch minimum of bytes requested and bytes available */
+
+ xbytes = size;
+ if (cookie\->offset + size > cookie\->endpos)
+ xbytes = cookie\->endpos \- cookie\->offset;
+ if (xbytes < 0) /* offset may be past endpos */
+ xbytes = 0;
+
+ memcpy(buf, cookie\->buf + cookie\->offset, xbytes);
+
+ cookie\->offset += xbytes;
+ return xbytes;
+}
+
+int
+memfile_seek(void *c, off64_t *offset, int whence)
+{
+ off64_t new_offset;
+ struct memfile_cookie *cookie = c;
+
+ if (whence == SEEK_SET)
+ new_offset = *offset;
+ else if (whence == SEEK_END)
+ new_offset = cookie\->endpos + *offset;
+ else if (whence == SEEK_CUR)
+ new_offset = cookie\->offset + *offset;
+ else
+ return \-1;
+
+ if (new_offset < 0)
+ return \-1;
+
+ cookie\->offset = new_offset;
+ *offset = new_offset;
+ return 0;
+}
+
+int
+memfile_close(void *c)
+{
+ struct memfile_cookie *cookie = c;
+
+ free(cookie\->buf);
+ cookie\->allocated = 0;
+ cookie\->buf = NULL;
+
+ return 0;
+}
+
+int
+main(int argc, char *argv[])
+{
+ cookie_io_functions_t memfile_func = {
+ .read = memfile_read,
+ .write = memfile_write,
+ .seek = memfile_seek,
+ .close = memfile_close
+ };
+ FILE *stream;
+ struct memfile_cookie mycookie;
+ ssize_t nread;
+ long p;
+ int j;
+ char buf[1000];
+
+ /* Set up the cookie before calling fopencookie() */
+
+ mycookie.buf = malloc(INIT_BUF_SIZE);
+ if (mycookie.buf == NULL) {
+ perror("malloc");
+ exit(EXIT_FAILURE);
+ }
+
+ mycookie.allocated = INIT_BUF_SIZE;
+ mycookie.offset = 0;
+ mycookie.endpos = 0;
+
+ stream = fopencookie(&mycookie,"w+", memfile_func);
+ if (stream == NULL) {
+ perror("fopencookie");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Write command\-line arguments to our file */
+
+ for (j = 1; j < argc; j++)
+ if (fputs(argv[j], stream) == EOF) {
+ perror("fputs");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Read two bytes out of every five, until EOF */
+
+ for (p = 0; ; p += 5) {
+ if (fseek(stream, p, SEEK_SET) == \-1) {
+ perror("fseek");
+ exit(EXIT_FAILURE);
+ }
+ nread = fread(buf, 1, 2, stream);
+ if (nread == \-1) {
+ perror("fread");
+ exit(EXIT_FAILURE);
+ }
+ if (nread == 0) {
+ printf("Reached end of file\en");
+ break;
+ }
+
+ printf("/%.*s/\en", nread, buf);
+ }
+
+ exit(EXIT_SUCCESS);
+}
+.fi
+.SH 関連項目
+\fBfclose\fP(3), \fBfmemopen\fP(3), \fBfopen\fP(3), \fBfseek\fP(3)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.78 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
--- /dev/null
+.\" Copyright (c) 1992, 1993, 1994
+.\" The Regents of the University of California. All rights reserved.
+.\" and Copyright (C) 2008, 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.\" %%%LICENSE_START(BSD_3_CLAUSE_UCB)
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\" may be used to endorse or promote products derived from this software
+.\" without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" %%%LICENSE_END
+.\"
+.\" @(#)symlink.7 8.3 (Berkeley) 3/31/94
+.\" $FreeBSD: src/bin/ln/symlink.7,v 1.30 2005/02/13 22:25:09 ru Exp $
+.\"
+.\" 2008-06-11, mtk, Taken from FreeBSD 6.2 and heavily edited for
+.\" specific Linux details, improved readability, and man-pages style.
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH SYMLINK 7 2014\-04\-06 Linux "Linux Programmer's Manual"
+.SH 名前
+symlink \- シンボリックリンクの取り扱い
+.SH 説明
+シンボリックリンクは他のファイルへのポインタとして振る舞うファイルである。
+その挙動を理解するには、まずハードリンクがどのように機能するかを理解しておかなければならない。
+
+あるファイルへのハードリンクは、 元々のファイルと区別することができない。 なぜなら、
+ハードリンクは元々のファイル名の裏にあるオブジェクトへの参照だからである。 (より正確には、 あるファイルへのハードリンクはそれぞれ同じ \fIinode
+番号\fP への参照である。 inode 番号は inode テーブルへのインデックスで、 inode
+テーブルはファイルシステム上のすべてのファイルについてのメタデータを保持している。 \fBstat\fP(2) 参照。)
+ファイルへの変更は、ファイルの参照に使用された名前とは独立に行われる。 ハードリンクはディレクトリを参照することはできない
+(これはファイルシステムツリー内でループが発生する可能性を防止するためであり、 ループが発生すると、 多くのプログラムが混乱してしまうことだろう)。
+また、 ハードリンクは異なるファイルシステム上のファイルを参照することもできない (inode
+番号はファイルシステムをまたがると一意ではないからである)。
+
+シンボリックリンクは特別な種類のファイルで、 ファイルの内容はそのリンクの参照先の別のファイルのパス名を示す文字列である (シンボリックリンクの内容は
+\fBreadlink\fP(2) を使って読むことができる)。 言い換えると、 シンボリックリンクは別の名前へのポインタであり、
+ファイルの裏にあるオブジェクトへのポインタではない。 この理由から、
+シンボリックリンクではディレクトリへの参照やファイルシステム境界を越える参照を行うことができる。
+
+シンボリックリンクが参照する先のパス名が存在しないといけないという要件はない。 存在しないパス名を参照するシンボリックリンクは「壊れた
+(dangling) リンク」と呼ばれる。
+
+シンボリックリンクとその参照先のオブジェクトは一つのファイルシステムの名前空間内に共存するので、
+リンクそのものと参照先のオブジェクトの間で混乱が生じる可能性がある。 かなり昔からあるシステムでは、
+コマンドやシステムコールはいくらかアドホックな方法の独自のリンクの辿り方の決まり事を採用している。 ここでは、 Linux
+や他のシステムで実装されている、 もっと広く使われている方法のルールについて概要を説明する。 サイト固有のアプリケーションもこれらのルールに準拠し、
+可能な限りユーザインターフェースが一貫したものになるようにすることが重要である。
+.SS シンボリックリンクの所有権、アクセス許可、タイムスタンプ
+既存のシンボリックリンクの所有者とグループは \fBlchown\fP(2) を使って変更することができる。 シンボリックリンクの所有権が問題となる場面は、
+スティッキービット (\fBstat\fP(2) 参照) がセットされたディレクトリで、 そのリンクの削除や名前の変更を行おうとしている場合だけである。
+
+シンボリックリンクの最終アクセス時刻と最終修正時刻は \fButimensat\fP(2) や \fBlutimes\fP(3) で変更できる。
+
+.\" Linux does not currently implement an lchmod(2).
+.\"
+.\" The
+.\" 4.4BSD
+.\" system differs from historical
+.\" 4BSD
+.\" systems in that the system call
+.\" .BR chown (2)
+.\" has been changed to follow symbolic links.
+.\" The
+.\" .BR lchown (2)
+.\" system call was added later when the limitations of the new
+.\" .BR chown (2)
+.\" became apparent.
+Linux では、シンボリックリンクのアクセス許可 (permission) はどの操作でも使用されない。 アクセス許可は常に 0777
+(すべてのユーザカテゴリにおいて読み出し、書き込み、実行が可能) で、変更できない。
+.SS シンボリックリンクを参照するファイルディスクリプタを取得する
+\fBopen\fP(2) に \fBO_PATH\fP と \fBO_NOFOLLOW\fP
+の両方のフラグを指定すると、ファイルディスクリプターが得られる。このファイルディスクリプターは \fBfstatat\fP(2),
+\fBfchownat\fP(2), \fBfchmodat\fP(2), \fBlinkat\fP (2), \fBreadlinkat\fP(2) などのシステムコールの
+\fIdirfd\fP 引き数として渡して、 (シンボリックリンクが参照するファイルではなく) シンボリックリンク自身に対する操作を行うことができる。
+
+デフォルトでは (すなわち \fBAT_SYMLINK_FOLLOW\fP フラグが指定されなかった場合)、 \fBname_to_handle_at\fP(2)
+がシンボリックリンクに適用された場合、 (シンボリックリンクが参照するファイルではなく) シンボリックリンクへのハンドルが返される。 それ以降の
+\fBopen_by_handle_at\fP(2) で \fBO_PATH\fP フラグを指定することで、 (シンボリックリンクが参照するファイルではなく)
+シンボリックリンクに対するファイルディスクリプターを得ることができる。 繰り返しになるが、 このファイルディスクリプターを上述のシステムコールで使用し、
+シンボリックリンク自身に操作を行うことができる。
+.SS システムコールやコマンドによるシンボリックリンクの取り扱い
+シンボリックリンクは、 リンク自身に対する操作か、 リンクが参照するオブジェクトに対する操作のいずれかとして扱われる。 後者の場合、
+アプリケーションやシステムコールはリンクを\fI辿る (follow)\fPと呼ばれる。 シンボリックリンクは他のシンボリックリンクを参照することもできる。
+この場合、 シンボリックリンクでないオブジェクトが見つかるか、 存在しないファイルを参照するシンボリックリンクが見つかるか、 ループが検出されるまで、
+リンクの展開が行われる。 (ループの検出は辿ることができるリンクの数に上限を設けることで行われる。 この上限を超過した場合はエラーとなる。)
+
+3 つの領域に分けて議論する必要がある。以下の 3 つである。
+.IP 1. 3
+システムコールのファイル名引き数としてシンボリックリンクが使用される場合。
+.IP 2.
+ファイルツリーを辿っていないユーティリティーのコマンドライン引き数としてシンボリックリンクが指定される場合。
+.IP 3.
+ファイルツリーを辿っているユーティリティーがシンボリックリンクを見つけた場合 (コマンドラインで指定される場合もあれば、
+ファイル階層を辿っている途中で遭遇する場合もある)。
+.SS システムコール
+最初の領域は、システムコールのファイル名引き数としてシンボリックリンクが使用される場合である。
+
+以下に述べる場合を除くと、 すべてのシステムコールはシンボリックリンクを辿る。 例えば、 \fIafile\fP
+という名前のファイルを指しているシンボリックリンク \fIslink\fP があったとすると、 システムコール \fIopen("slink" ...\&)\fP
+はファイル \fIafile\fP を参照するファイルディスクリプタを返す。
+
+リンクを辿らず、シンボリックリンク自身に対して操作を行うシステムコールもある。 このようなシステムコールとしては、 \fBlchown\fP(2),
+\fBlgetxattr\fP(2), \fBllistxattr\fP(2), \fBlremovexattr\fP(2), \fBlsetxattr\fP(2),
+\fBlstat\fP(2), \fBreadlink\fP(2), \fBrename\fP(2), \fBrmdir\fP(2), \fBunlink\fP(2) がある。
+
+.\" Maybe one day: .BR fchownat (2)
+他のいくつかのシステムコールは、指定された場合にのみシンボリックリンクを辿る。 これらのシステムコールとしては、 \fBfaccessat\fP(2),
+\fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2), \fBname_to_handle_at\fP(2),
+\fBopen\fP(2), \fBopenat\fP(2), \fBopen_by_handle_at\fP(2), \fButimensat\fP(2) がある。
+詳細はそれぞれのマニュアルページを参照してほしい。 \fBremove\fP(3) は \fBunlink\fP(2) の別名なので、
+このライブラリ関数もシンボリックリンクを辿らない。 \fBrmdir\fP(2) がシンボリックリンクに対して行われた場合、その呼び出しはエラー
+\fBENOTDIR\fP で失敗する。
+
+\fBlink\fP(2) については特別に議論が必要である。 POSIX.1\-2001 では \fBlink\fP(2) は \fIoldpath\fP
+がシンボリックリンクであればこれを展開するように規定している。 しかしながら、 Linux はシンボリックリンクを展開しない。 (デフォルトでは
+Solaris も同じだが、 適切なコンパイラーオプションを指定することで POSIX.1\-2001 で規定された動作をさせることができる。)
+今後のバージョンの POSIX.1 では、どちらの動作の実装も認められるように規定が変更される。
+.SS ファイルツリーを辿らないコマンド
+二つ目の領域は、 ファイルツリーを辿らないコマンドの、 コマンドライン引き数のファイル名としてシンボリックリンクが指定される場合である。
+
+以下に述べる場合を除くと、 コマンドはコマンドライン引き数で指定された名前のシンボリックリンクを辿る。 例えば、 \fIafile\fP
+という名前のファイルを指しているシンボリックリンク \fIslink\fP があったとすると、 コマンド \fIcat slink\fP は \fIafile\fP
+の内容を表示することになる。
+
+大事な点として意識しておくべきなのは、 このルールが適用されるコマンドの中には、
+オプション次第ではファイルツリーを辿る場合があるコマンドもあるということである。 例えば、 コマンド \fIchown file\fP
+はこのルールに含まれるが、 コマンド \fIchown\ \-R file\fP はツリーを辿る動作をするのであてはまらない (後者の場合は、3
+つ目の領域に該当する)。
+
+シンボリックリンクを辿るのではなく、 コマンドがシンボリックリンク自身に対して操作を行うことを明示的に指示したい場合、 例えば、 \fIchown
+slink\fP で \fIslink\fP がシンボリックリンクかどうかに関わらず、 \fIslink\fP のファイル自身の所有権を変更したい場合は、 \fI\-h\fP
+オプションを使用すべきである。 上記の例では、 \fIchown root slink\fP は \fIslink\fP が参照するファイルの所有権を変更するが、
+\fIchown\ \-h root slink\fP は \fIslink\fP 自身の所有権を変更する。
+
+このルールにはいくつかの例外がある。
+.IP * 2
+コマンド \fBmv\fP(1) と \fBrm\fP(1) は引き数で指定された名前のシンボリックリンクを辿らないが、
+それぞれシンボリックリンク自身の名前変更と削除を行おうとする。 (シンボリックリンクが相対パスでファイルを参照している場合、
+そのシンボリックリンクを別のディレクトリに移動すると、動かなくなることが非常によくある。 移動の結果、 パスが正しくないものになってしまうからである。)
+.IP *
+\fBls\fP(1) コマンドもこのルールの例外である。 昔からあるシステムとの互換性のため (\fBls\fP(1) がツリーを辿らない場合、つまり \fI\-R\fP
+オプションが指定されなかった場合)、 \fBls\fP(1) コマンドはオプション \fI\-H\fP か \fI\-L\fP が指定された場合、もしくはオプション
+\fI\-F\fP, \fI\-d\fP, \fI\-l\fP が指定されなかった場合、 引き数として指定されたシンボリックリンクを辿る。 (\fBls\fP(1) コマンドは、
+ファイルツリーを辿らない場合であっても、 オプション \fI\-H\fP と \fI\-L\fP がその動作に影響を与える唯一のコマンドである。)
+.IP *
+.\"
+.\"The 4.4BSD system differs from historical 4BSD systems in that the
+.\".BR chown (1)
+.\"and
+.\".BR chgrp (1)
+.\"commands follow symbolic links specified on the command line.
+\fBfile\fP(1) コマンドもこのルールの例外である。 \fBfile\fP(1) コマンドは、
+デフォルトでは引き数で指定されたシンボリックリンクを辿らない。 \fBfile\fP(1) コマンドは、 \fI\-L\fP オプションが指定された場合、
+引き数で指定されたシンボリックリンクを辿る。
+.SS ファイルツリーを辿るコマンド
+次のコマンドは指定された場合もしくは常にファイルツリーを辿る: \fBchgrp\fP(1), \fBchmod\fP(1), \fBchown\fP(1),
+\fBcp\fP(1), \fBdu\fP(1), \fBfind\fP(1), \fBls\fP(1), \fBpax\fP(1), \fBrm\fP(1), \fBtar\fP(1)。
+
+重要なのは、 ファイルツリーを辿っている際に見つかったシンボリックリンクにも、 コマンドライン引き数として渡されたシンボリックリンクにも、
+以下のルールが等しく適用される点である。
+
+「1 つ目のルール」は、 ディレクトリ以外のファイルを参照するシンボリックリンクに適用される。
+シンボリックリンクに適用される操作はシンボリックリンク自身に行われるが、 そうでない場合はリンクは無視される。
+
+コマンド \fIrm\ \-r slink directory\fP は \fIslink\fP を削除するとともに、
+ファイルツリーを辿る途中で見つけたシンボリックリンクも削除する。 シンボリックリンクは削除できるからである。 \fBrm\fP(1) が \fIslink\fP
+が参照するファイルに影響をおよぼすことはない。
+
+「2 つ目のルール」は、 ディレクトリを参照するシンボリックリンクに適用される。 デフォルトでは、 ディレクトリを参照するシンボリックリンクを辿らない。
+この動作はしばしば「物理的な」ツリー探索 ("physical" walk) と呼ばれる。 これに対して
+(ディレクトリを参照するシンボリックリンクを辿る場合は) 「論理的な」ツリー探索 ("logical" walk) と呼ばれる。
+
+一貫性を持たせるため、ファイルツリーを辿るコマンドが可能な限り従っている慣習がいくつかある。
+.IP * 2
+\fI\-H\fP ("half\-logical") フラグを指定すると、 参照先のファイル種別に関わらず、
+コマンドにコマンドラインで指定されたシンボリックリンクを辿らせることができる。 このフラグは、
+コマンドラインの名前空間を論理的な名前空間のように見せるためのものである。 (常にファイルツリーを辿るわけではないコマンドでは、 \fI\-R\fP
+フラグを一緒に指定しない限り、 \fI\-H\fP フラグは無視される点に注意。)
+
+例えば、 コマンド \fIchown\ \-HR user slink\fP は \fIslink\fP が指すファイルを頂点とするファイル階層を辿る。 \fI\-H\fP
+は上記で説明した \fI\-h\fP フラグとは同じではないことに注意。 \fI\-H\fP フラグを指定すると、 アクションを実行する場合でも、
+ツリーを辿る場合でも、 コマンドラインで指定されたシンボリックリンクの解決 (dereference) を行う。
+ユーザーがシンボリックリンクが指すファイル名を指定したのと同じように見える。
+.IP *
+\fI\-L\fP ("logical") フラグを指定すると、 参照先のファイル種別に関わらず、 コマンドが、
+コマンドラインで指定された名前のシンボリックリンクも、 ファイルツリーを辿る際に見つけたシンボリックリンクも辿るようになる。 このフラグは、
+名前空間全体を論理的な名前空間のように見せるためのものである。 (常にファイルツリーを辿るわけではないコマンドでは、 \fI\-R\fP
+フラグを一緒に指定しない限り、 \fI\-L\fP フラグは無視される点に注意。)
+
+例えば、 コマンド \fIchown\ \-LR user slink\fP は \fIslink\fP が参照するファイルの所有者を変更する。
+\fIslink\fP がディレクトリを参照する場合、 \fBchown\fP はそのシンボリックリンクが参照するディレクトリを頂点とするファイル階層を辿る。
+また、 \fBchown\fP が辿るファイルツリー内でシンボリックリンクが見つかった場合、 \fIslink\fP と同じように処理される。
+.IP *
+\fI\-P\fP ("physical") フラグを指定すると、 コマンドはデフォルトの動作をするようになる。
+このフラグは名前空間全体を物理的な名前空間のように見せるためのものである。
+.PP
+デフォルトでファイルツリーを辿らないコマンドでは、 \fI\-R\fP フラグが同時に指定されなかった場合、 フラグ \fI\-H\fP, \fI\-L\fP, \fI\-P\fP
+は無視される。 また、 \fI\-H\fP, \fI\-L\fP, \fI\-P\fP は複数回同時に指定できるが、 最後に指定されたオプションでコマンドの動作が決定される。
+この動作は、 コマンドのエイリアスにある動作を指定しておいて、 コマンドラインでその動作を上書きできるようにするためである。
+
+コマンド \fBls\fP(1) と \fBrm\fP(1) には、 これらのルールに対する例外がある。
+.IP * 2
+\fBrm\fP(1) コマンドは、 参照先のファイルではなく、シンボリックリンクに対して操作を行う。 したがって、 シンボリックリンクを辿ることはない。
+\fBrm\fP(1) コマンドはオプション \fI\-H\fP, \fI\-L\fP, \fI\-P\fP をサポートしていない。
+.IP *
+古いシステムとの互換性を持たせるため、 \fBls\fP(1) コマンドは少し違った動作をする。 オプション \fI\-F\fP, \fI\-d\fP, \fI\-l\fP
+を指定した場合、 \fBls\fP(1) はコマンドラインで指定されたシンボリックリンクを辿る。 \fI\-L\fP フラグが指定された場合、
+コマンドラインで指定された場合でも、 ファイルツリーを辿る際に見つかった場合でも、 ファイル種別に関わらず、 \fBls\fP(1)
+はすべてのシンボリックリンクを辿る。
+.SH 関連項目
+\fBchgrp\fP(1), \fBchmod\fP(1), \fBfind\fP(1), \fBln\fP(1), \fBls\fP(1), \fBmv\fP(1),
+\fBrm\fP(1), \fBlchown\fP(2), \fBlink\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2),
+\fBrename\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fButimensat\fP(2),
+\fBlutimes\fP(3), \fBpath_resolution\fP(7)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.78 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-01-23 22:23+0900\n"
-"PO-Revision-Date: 2015-01-24 03:47+0900\n"
+"PO-Revision-Date: 2015-01-24 07:50+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
#. type: Plain text
#: build/C/man3/fopencookie.3:29
msgid "fopencookie - opening a custom stream"
-msgstr ""
+msgstr "fopencookie - 独自のストリームをオープンする"
#. type: Plain text
#: build/C/man3/fopencookie.3:36
"B<fopencookie>() is used to implement B<fmemopen>(3), which provides a "
"stream interface to data that is stored in a buffer in memory."
msgstr ""
+"B<fopencookie>() を使うと、 プログラマーは標準 I/O ストリームの独自の実装を作成することができる。\n"
+"この実装はストリームのデータを自分が選んだ場所に格納することができる。 例えば、 B<fopencookie>() は B<fmemopen>(3) を実装するのに使用されている。 B<fmemopen>(3) はメモリー上のバッファーに格納されたデータに対するストリームインターフェースを提供している。"
#. type: Plain text
#: build/C/man3/fopencookie.3:51
msgid "In order to create a custom stream the programmer must:"
-msgstr ""
+msgstr "独自のストリームを作成するためには、 プログラマーは以下を行う必要がある。"
#. type: IP
#: build/C/man3/fopencookie.3:51 build/C/man3/fopencookie.3:54
msgid ""
"Implement four \"hook\" functions that are used internally by the standard I/"
"O library when performing I/O on the stream."
-msgstr ""
+msgstr "ストリームに対する I/O を実行する際に標準 I/O ライブラリが内部で使用する 4 つの \"フック\" 関数を実装する。"
#. type: Plain text
#: build/C/man3/fopencookie.3:65
"this cookie (thus it is typed as I<void\\ *> when passed to "
"B<fopencookie>()), but automatically supplies the cookie as the first "
"argument when calling the hook functions."
-msgstr ""
+msgstr "\"cookie\" データ型を定義する。 \"cookie\" データ型は、上記のフック関数が使用する管理情報 (例えば、データを格納する場所など) を提供する構造体である。 標準の I/O パッケージにはこの cookie の内容に関する情報を持たないが (したがって B<fopencookie>() に渡される際の型は I<void\\ *> である)、 フック関数が呼び出される際に第一引き数として cookie が渡される。"
#. type: Plain text
#: build/C/man3/fopencookie.3:70
msgid ""
"Call B<fopencookie>() to open a new stream and associate the cookie and "
"hook functions with that stream."
-msgstr ""
+msgstr "B<fopencookie>() を呼び出して、新しいストリームをオープンし、 そのストリームに cookie とフック関数を関連付ける。"
#. type: Plain text
#: build/C/man3/fopencookie.3:78
"The B<fopencookie>() function serves a purpose similar to B<fopen>(3): it "
"opens a new stream and returns a pointer to a I<FILE> object that is used to "
"operate on that stream."
-msgstr ""
+msgstr "B<fopencookie>() 関数は B<fopen>(3) と同様の機能を持つ。 新しいストリームをオープンし、 そのストリームに対して操作を行うのに使用する I<FILE> オブジェクトへのポインターを返す。"
#. type: Plain text
#: build/C/man3/fopencookie.3:85
"to be associated with the new stream. This pointer is supplied as the first "
"argument when the standard I/O library invokes any of the hook functions "
"described below."
-msgstr ""
+msgstr "I<cookie> 引き数は、 新しいストリームに関連付けられる呼び出し元の cookie 構造体へのポインターである。 このポインターは、 標準 I/O ライブラリが以下で説明するフック関数のいずれかを呼び出す際に第 1 引き数として渡される。"
#. type: Plain text
#: build/C/man3/fopencookie.3:101
"The I<mode> argument serves the same purpose as for B<fopen>(3). The "
"following modes are supported: I<r>, I<w>, I<a>, I<r+>, I<w+>, and I<a+>. "
"See B<fopen>(3) for details."
-msgstr ""
+msgstr "I<mode> 引き数は B<fopen>(3) と同じ意味を持つ。 指定できるモードは I<r>, I<w>, I<a>, I<r+>, I<w+>, I<a+> である。 詳細は B<fopen>(3) を参照。"
#. type: Plain text
#: build/C/man3/fopencookie.3:107
"The I<io_funcs> argument is a structure that contains four fields pointing "
"to the programmer-defined hook functions that are used to implement this "
"stream. The structure is defined as follows"
-msgstr ""
+msgstr "I<io_funcs> 引き数は、 このストリームを実装するのに使用されるプログラマーが定義した関数を指す 4 つのフィールドを持つ構造体である。 この構造体は以下のように定義されている。"
#. type: Plain text
#: build/C/man3/fopencookie.3:116
#. type: Plain text
#: build/C/man3/fopencookie.3:120
msgid "The four fields are as follows:"
-msgstr ""
+msgstr "4 つのフィールドの詳細は以下のとおりである。"
#. type: TP
#: build/C/man3/fopencookie.3:120
msgid ""
"This function implements read operations for the stream. When called, it "
"receives three arguments:"
-msgstr ""
+msgstr "この関数はストリームに対する read 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。"
#. type: Plain text
#: build/C/man3/fopencookie.3:126
"result, the I<read> function should return the number of bytes copied into "
"I<buf>, 0 on end of file, or -1 on error. The I<read> function should "
"update the stream offset appropriately."
-msgstr ""
+msgstr "引き数 I<buf> と I<size> は、 それぞれ、 入力データを配置できるバッファーとそのバッファーのサイズである。 関数の結果として、 I<read> 関数は I<buf> にコピーされたバイト数を、 ファイル末尾の場合は 0 を、 エラーの場合は -1 を返す。 I<read> 関数はストリームのオフセットを適切に更新すべきである。"
#. type: Plain text
#: build/C/man3/fopencookie.3:146
msgid ""
"If I<*read> is a null pointer, then reads from the custom stream always "
"return end of file."
-msgstr ""
+msgstr "I<*read> がヌルポインターの場合、 独自のストリームからの読み出しは常にファイル末尾 (end of file) を返す。"
#. type: TP
#: build/C/man3/fopencookie.3:146
msgid ""
"This function implements write operations for the stream. When called, it "
"receives three arguments:"
-msgstr ""
+msgstr "この関数はストリームに対する write 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。"
#. type: Plain text
#: build/C/man3/fopencookie.3:152
"the I<write> function should return the number of bytes copied from I<buf>, "
"or 0 on error. (The function must not return a negative value.) The "
"I<write> function should update the stream offset appropriately."
-msgstr ""
+msgstr "引き数 I<buf> と I<size> は、 それぞれ、 ストリームへの出力するデータが入ったバッファーとそのバッファーのサイズである。 関数の結果として、 I<write> 関数は I<buf> からコピーされたバイト数を返し、 エラーの場合は -1 を返す。 (この関数は負の値を返してはならない。) I<write> 関数はストリームのオフセットを適切に更新すべきである。"
#. type: Plain text
#: build/C/man3/fopencookie.3:173
msgid "If I<*write> is a null pointer, then output to the stream is discarded."
-msgstr ""
+msgstr "I<*write> がヌルポインターの場合、 このストリームへの出力は破棄される。"
#. type: TP
#: build/C/man3/fopencookie.3:173
msgid ""
"This function implements seek operations on the stream. When called, it "
"receives three arguments:"
-msgstr ""
+msgstr "この関数はストリームに対する seek 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。"
#. type: Plain text
#: build/C/man3/fopencookie.3:179
msgid ""
"The I<*offset> argument specifies the new file offset depending on which of "
"the following three values is supplied in I<whence>:"
-msgstr ""
+msgstr "I<*offset> 引き数は新しいファイルオフセットを指定する。 新しいオフセットは I<whence> に以下の値のどれが指定されたかに応じて決まる。"
#. type: TP
#: build/C/man3/fopencookie.3:186 build/C/man2/lseek.2:67
msgid ""
"The stream offset should be set I<*offset> bytes from the start of the "
"stream."
-msgstr ""
+msgstr "ストリームオフセットを、ストリームの先頭から I<*offset> バイトの位置に設定する。"
#. type: TP
#: build/C/man3/fopencookie.3:191 build/C/man2/lseek.2:72
#. type: Plain text
#: build/C/man3/fopencookie.3:195
msgid "I<*offset> should be added to the current stream offset."
-msgstr ""
+msgstr "ストリームの現在のオフセットに I<*offset> を加算する。"
#. type: TP
#: build/C/man3/fopencookie.3:195 build/C/man2/lseek.2:77
#: build/C/man3/fopencookie.3:199
msgid ""
"The stream offset should be set to the size of the stream plus I<*offset>."
-msgstr ""
+msgstr "ストリームのオフセットを、ストリームのサイズに I<*offset> を足した場所に設定する。"
#. type: Plain text
#: build/C/man3/fopencookie.3:206
msgid ""
"Before returning, the I<seek> function should update I<*offset> to indicate "
"the new stream offset."
-msgstr ""
+msgstr "関数が返る前に、 I<seek> 関数はストリームの新しいオフセットを示すように I<*offset> を更新すべきである。"
#. type: Plain text
#: build/C/man3/fopencookie.3:210
msgid ""
"As its function result, the I<seek> function should return 0 on success, and "
"-1 on error."
-msgstr ""
+msgstr "関数の結果として、 I<seek> 関数は成功すると 0 を、 エラーの場合 -1 を返す。"
#. type: Plain text
#: build/C/man3/fopencookie.3:215
msgid ""
"If I<*seek> is a null pointer, then it is not possible to perform seek "
"operations on the stream."
-msgstr ""
+msgstr "I<*seek> がヌルポインターの場合、 このストリームに対して seek 操作を行うことができない。"
#. type: TP
#: build/C/man3/fopencookie.3:215
"This function closes the stream. The hook function can do things such as "
"freeing buffers allocated for the stream. When called, it receives one "
"argument:"
-msgstr ""
+msgstr "この関数はストリームをクローズする。 このフック関数では、 このストリームに割り当てられたバッファを解放するといったことができる。 呼び出される際、 1 つの引き数を受け取る。"
#. type: Plain text
#: build/C/man3/fopencookie.3:223
msgid ""
"The I<cookie> argument is the cookie that the programmer supplied when "
"calling B<fopencookie>()."
-msgstr ""
+msgstr "I<cookie> 引き数は B<fopencookie>() の呼び出し時にプログラマーが渡した cookie である。"
#. type: Plain text
#: build/C/man3/fopencookie.3:234
msgid ""
"As its function result, the I<close> function should return 0 on success, "
"and B<EOF> on error."
-msgstr ""
+msgstr "関数の結果として、 I<close> 関数は成功すると 0 を、 エラーの場合 B<EOF> を返す。"
#. type: Plain text
#: build/C/man3/fopencookie.3:238
msgid ""
"If I<*close> is NULL, then no special action is performed when the stream is "
"closed."
-msgstr ""
+msgstr "I<*close> が NULL の場合、 ストリームがクローズされる際に特別な操作は何も行われない。"
#. .SH ERRORS
#. It's not clear if errno ever gets set...
msgid ""
"On success B<fopencookie>() returns a pointer to the new stream. On error, "
"NULL is returned."
-msgstr ""
+msgstr "成功すると B<fopencookie>() は新しいストリームへのポインターを返す。 エラーの場合、 NULL が返される。"
#. type: Plain text
#: build/C/man3/fopencookie.3:247
msgid "This function is a nonstandard GNU extension."
-msgstr ""
+msgstr "この関数は非標準の GNU 拡張である。"
#. type: Plain text
#: build/C/man3/fopencookie.3:256
"command-line arguments to the stream, and then seeks through the stream "
"reading two out of every five characters and writing them to standard "
"output. The following shell session demonstrates the use of the program:"
-msgstr ""
+msgstr "以下のプログラムは、 B<fmemopen>(3) で利用できるのと似た (同じではない) 機能を持つ独自のストリームを実装している。 データがメモリーバッファーに格納されるストリームを実装している。 このプログラムは、 コマンドライン引き数をストリームに書き込み、 それからストリームをたどって 5 文字ごとに 2 文字を読み出して、 それを標準出力に書き込む。 以下のシェルセッションはこのプログラムの使用例である。"
#. type: Plain text
#: build/C/man3/fopencookie.3:264
"more robustly handle various error situations (e.g., opening a stream with a "
"cookie that already has an open stream; closing a stream that has already "
"been closed)."
-msgstr ""
+msgstr "このプログラムを改良して様々なエラー状況に強くすることもできる (例えば、 オープン済みのストリームに対応する cookie でストリームをオープンしようとした、 すでにクローズされたストリームをクローズしようとした、など)。"
#. type: Plain text
#: build/C/man3/fopencookie.3:280
msgid ""
"Certain conventions are (should be) followed as consistently as possible by "
"commands that perform file tree walks:"
-msgstr ""
+msgstr "一貫性を持たせるため、ファイルツリーを辿るコマンドが可能な限り従っている慣習がいくつかある。"
#. type: Plain text
#: build/C/man7/symlink.7:403
"name space look like the logical name space. (Note, for commands that do "
"not always do file tree traversals, the I<-H> flag will be ignored if the I<-"
"R> flag is not also specified.)"
-msgstr ""
+msgstr "I<-H> (\"half-logical\") フラグを指定すると、 参照先のファイル種別に関わらず、 コマンドにコマンドラインで指定されたシンボリックリンクを辿らせることができる。 このフラグは、 コマンドラインの名前空間を論理的な名前空間のように見せるためのものである。 (常にファイルツリーを辿るわけではないコマンドでは、 I<-R> フラグを一緒に指定しない限り、 I<-H> フラグは無視される点に注意。)"
#. type: Plain text
#: build/C/man7/symlink.7:419
"purposes of both the action to be performed and the tree walk, and it is as "
"if the user had specified the name of the file to which the symbolic link "
"pointed."
-msgstr ""
+msgstr "例えば、 コマンド I<chown\\ -HR user slink> は I<slink> が指すファイルを頂点とするファイル階層を辿る。 I<-H> は上記で説明した I<-h> フラグとは同じではないことに注意。 I<-H> フラグを指定すると、 アクションを実行する場合でも、 ツリーを辿る場合でも、 コマンドラインで指定されたシンボリックリンクの解決 (dereference) を行う。 ユーザーがシンボリックリンクが指すファイル名を指定したのと同じように見える。"
#. type: Plain text
#: build/C/man7/symlink.7:433
"like the logical name space. (Note, for commands that do not always do file "
"tree traversals, the I<-L> flag will be ignored if the I<-R> flag is not "
"also specified.)"
-msgstr ""
+msgstr "I<-L> (\"logical\") フラグを指定すると、 参照先のファイル種別に関わらず、 コマンドが、 コマンドラインで指定された名前のシンボリックリンクも、 ファイルツリーを辿る際に見つけたシンボリックリンクも辿るようになる。 このフラグは、 名前空間全体を論理的な名前空間のように見せるためのものである。 (常にファイルツリーを辿るわけではないコマンドでは、 I<-R> フラグを一緒に指定しない限り、 I<-L> フラグは無視される点に注意。)"
#. type: Plain text
#: build/C/man7/symlink.7:448
"tree that B<chown> traverses, they will be treated in the same fashion as "
"I<slink>."
msgstr ""
+"例えば、 コマンド I<chown\\ -LR user slink> は I<slink> が参照するファイルの所有者を変更する。\n"
+"I<slink> がディレクトリを参照する場合、 B<chown> はそのシンボリックリンクが参照するディレクトリを頂点とするファイル階層を辿る。 また、 B<chown> が辿るファイルツリー内でシンボリックリンクが見つかった場合、 I<slink> と同じように処理される。"
#. type: Plain text
#: build/C/man7/symlink.7:455
"A command can be made to provide the default behavior by specifying the I<-"
"P> (for \"physical\") flag. This flag is intended to make the entire name "
"space look like the physical name space."
-msgstr ""
+msgstr "I<-P> (\"physical\") フラグを指定すると、 コマンドはデフォルトの動作をするようになる。 このフラグは名前空間全体を物理的な名前空間のように見せるためのものである。"
#. type: Plain text
#: build/C/man7/symlink.7:473
"once; the last one specified determines the command's behavior. This is "
"intended to permit you to alias commands to behave one way or the other, and "
"then override that behavior on the command line."
-msgstr ""
+msgstr "デフォルトでファイルツリーを辿らないコマンドでは、 I<-R> フラグが同時に指定されなかった場合、 フラグ I<-H>, I<-L>, I<-P> は無視される。 また、 I<-H>, I<-L>, I<-P> は複数回同時に指定できるが、 最後に指定されたオプションでコマンドの動作が決定される。 この動作は、 コマンドのエイリアスにある動作を指定しておいて、 コマンドラインでその動作を上書きできるようにするためである。"
#. type: Plain text
#: build/C/man7/symlink.7:479
"line. If the I<-L> flag is specified, B<ls>(1) follows all symbolic links, "
"regardless of their type, whether specified on the command line or "
"encountered in the tree walk."
-msgstr ""
+msgstr "古いシステムとの互換性を持たせるため、 B<ls>(1) コマンドは少し違った動作をする。 オプション I<-F>, I<-d>, I<-l> を指定した場合、 B<ls>(1) はコマンドラインで指定されたシンボリックリンクを辿る。 I<-L> フラグが指定された場合、 コマンドラインで指定された場合でも、 ファイルツリーを辿る際に見つかった場合でも、 ファイル種別に関わらず、 B<ls>(1) はすべてのシンボリックリンクを辿る。"
#. type: Plain text
#: build/C/man7/symlink.7:530
--- /dev/null
+.\" Copyright (c) 2008, Linux Foundation, written by Michael Kerrisk
+.\" <mtk.manpages@gmail.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH FOPENCOOKIE 3 2015\-01\-22 Linux "Linux Programmer's Manual"
+.SH 名前
+fopencookie \- 独自のストリームをオープンする
+.SH 書式
+.nf
+\fB#define _GNU_SOURCE\fP /* feature_test_macros(7) 参照 */
+\fB#include <stdio.h>\fP
+
+\fBFILE *fopencookie(void *\fP\fIcookie\fP\fB, const char *\fP\fImode\fP\fB,\fP
+\fB cookie_io_functions_t \fP\fIio_funcs\fP\fB);\fP
+.fi
+.SH 説明
+\fBfopencookie\fP() を使うと、 プログラマーは標準 I/O ストリームの独自の実装を作成することができる。
+この実装はストリームのデータを自分が選んだ場所に格納することができる。 例えば、 \fBfopencookie\fP() は \fBfmemopen\fP(3)
+を実装するのに使用されている。 \fBfmemopen\fP(3)
+はメモリー上のバッファーに格納されたデータに対するストリームインターフェースを提供している。
+
+独自のストリームを作成するためには、 プログラマーは以下を行う必要がある。
+.IP * 3
+ストリームに対する I/O を実行する際に標準 I/O ライブラリが内部で使用する 4 つの "フック" 関数を実装する。
+.IP *
+"cookie" データ型を定義する。 "cookie" データ型は、上記のフック関数が使用する管理情報 (例えば、データを格納する場所など)
+を提供する構造体である。 標準の I/O パッケージにはこの cookie の内容に関する情報を持たないが (したがって
+\fBfopencookie\fP() に渡される際の型は \fIvoid\ *\fP である)、 フック関数が呼び出される際に第一引き数として cookie
+が渡される。
+.IP *
+\fBfopencookie\fP() を呼び出して、新しいストリームをオープンし、 そのストリームに cookie とフック関数を関連付ける。
+.PP
+\fBfopencookie\fP() 関数は \fBfopen\fP(3) と同様の機能を持つ。 新しいストリームをオープンし、
+そのストリームに対して操作を行うのに使用する \fIFILE\fP オブジェクトへのポインターを返す。
+
+\fIcookie\fP 引き数は、 新しいストリームに関連付けられる呼び出し元の cookie 構造体へのポインターである。 このポインターは、 標準
+I/O ライブラリが以下で説明するフック関数のいずれかを呼び出す際に第 1 引き数として渡される。
+
+\fImode\fP 引き数は \fBfopen\fP(3) と同じ意味を持つ。 指定できるモードは \fIr\fP, \fIw\fP, \fIa\fP, \fIr+\fP, \fIw+\fP,
+\fIa+\fP である。 詳細は \fBfopen\fP(3) を参照。
+
+\fIio_funcs\fP 引き数は、 このストリームを実装するのに使用されるプログラマーが定義した関数を指す 4 つのフィールドを持つ構造体である。
+この構造体は以下のように定義されている。
+.in +4n
+.nf
+
+typedef struct {
+ cookie_read_function_t *read;
+ cookie_write_function_t *write;
+ cookie_seek_function_t *seek;
+ cookie_close_function_t *close;
+} cookie_io_functions_t;
+
+.fi
+.in
+4 つのフィールドの詳細は以下のとおりである。
+.TP
+\fIcookie_read_function_t *read\fP
+この関数はストリームに対する read 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。
+
+ ssize_t read(void *cookie, char *buf, size_t size);
+
+引き数 \fIbuf\fP と \fIsize\fP は、 それぞれ、 入力データを配置できるバッファーとそのバッファーのサイズである。 関数の結果として、
+\fIread\fP 関数は \fIbuf\fP にコピーされたバイト数を、 ファイル末尾の場合は 0 を、 エラーの場合は \-1 を返す。 \fIread\fP
+関数はストリームのオフセットを適切に更新すべきである。
+
+\fI*read\fP がヌルポインターの場合、 独自のストリームからの読み出しは常にファイル末尾 (end of file) を返す。
+.TP
+\fIcookie_write_function_t *write\fP
+この関数はストリームに対する write 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。
+
+ ssize_t write(void *cookie, const char *buf, size_t size);
+
+引き数 \fIbuf\fP と \fIsize\fP は、 それぞれ、 ストリームへの出力するデータが入ったバッファーとそのバッファーのサイズである。
+関数の結果として、 \fIwrite\fP 関数は \fIbuf\fP からコピーされたバイト数を返し、 エラーの場合は \-1 を返す。
+(この関数は負の値を返してはならない。) \fIwrite\fP 関数はストリームのオフセットを適切に更新すべきである。
+
+\fI*write\fP がヌルポインターの場合、 このストリームへの出力は破棄される。
+.TP
+\fIcookie_seek_function_t *seek\fP
+この関数はストリームに対する seek 操作を実装する。 呼び出される際、 3 つの引き数を受け取る。
+
+ int seek(void *cookie, off64_t *offset, int whence);
+
+\fI*offset\fP 引き数は新しいファイルオフセットを指定する。 新しいオフセットは \fIwhence\fP
+に以下の値のどれが指定されたかに応じて決まる。
+.RS
+.TP 10
+\fBSEEK_SET\fP
+ストリームオフセットを、ストリームの先頭から \fI*offset\fP バイトの位置に設定する。
+.TP
+\fBSEEK_CUR\fP
+ストリームの現在のオフセットに \fI*offset\fP を加算する。
+.TP
+\fBSEEK_END\fP
+ストリームのオフセットを、ストリームのサイズに \fI*offset\fP を足した場所に設定する。
+.RE
+.IP
+関数が返る前に、 \fIseek\fP 関数はストリームの新しいオフセットを示すように \fI*offset\fP を更新すべきである。
+
+関数の結果として、 \fIseek\fP 関数は成功すると 0 を、 エラーの場合 \-1 を返す。
+
+\fI*seek\fP がヌルポインターの場合、 このストリームに対して seek 操作を行うことができない。
+.TP
+\fIcookie_close_function_t *close\fP
+この関数はストリームをクローズする。 このフック関数では、 このストリームに割り当てられたバッファを解放するといったことができる。 呼び出される際、 1
+つの引き数を受け取る。
+
+ int close(void *cookie);
+
+\fIcookie\fP 引き数は \fBfopencookie\fP() の呼び出し時にプログラマーが渡した cookie である。
+
+関数の結果として、 \fIclose\fP 関数は成功すると 0 を、 エラーの場合 \fBEOF\fP を返す。
+
+\fI*close\fP が NULL の場合、 ストリームがクローズされる際に特別な操作は何も行われない。
+.SH 返り値
+.\" .SH ERRORS
+.\" It's not clear if errno ever gets set...
+成功すると \fBfopencookie\fP() は新しいストリームへのポインターを返す。 エラーの場合、 NULL が返される。
+.SH 準拠
+この関数は非標準の GNU 拡張である。
+.SH 例
+以下のプログラムは、 \fBfmemopen\fP(3) で利用できるのと似た (同じではない) 機能を持つ独自のストリームを実装している。
+データがメモリーバッファーに格納されるストリームを実装している。 このプログラムは、 コマンドライン引き数をストリームに書き込み、
+それからストリームをたどって 5 文字ごとに 2 文字を読み出して、 それを標準出力に書き込む。 以下のシェルセッションはこのプログラムの使用例である。
+.in +4n
+.nf
+
+$\fB ./a.out \(aqhello world\(aq\fP
+/he/
+/ w/
+/d/
+Reached end of file
+
+.fi
+.in
+このプログラムを改良して様々なエラー状況に強くすることもできる (例えば、 オープン済みのストリームに対応する cookie
+でストリームをオープンしようとした、 すでにクローズされたストリームをクローズしようとした、など)。
+.SS プログラムのソース
+\&
+.nf
+#define _GNU_SOURCE
+#include <sys/types.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <string.h>
+
+#define INIT_BUF_SIZE 4
+
+struct memfile_cookie {
+ char *buf; /* Dynamically sized buffer for data */
+ size_t allocated; /* Size of buf */
+ size_t endpos; /* Number of characters in buf */
+ off_t offset; /* Current file offset in buf */
+};
+
+ssize_t
+memfile_write(void *c, const char *buf, size_t size)
+{
+ char *new_buff;
+ struct memfile_cookie *cookie = c;
+
+ /* Buffer too small? Keep doubling size until big enough */
+
+ while (size + cookie\->offset > cookie\->allocated) {
+ new_buff = realloc(cookie\->buf, cookie\->allocated * 2);
+ if (new_buff == NULL) {
+ return \-1;
+ } else {
+ cookie\->allocated *= 2;
+ cookie\->buf = new_buff;
+ }
+ }
+
+ memcpy(cookie\->buf + cookie\->offset, buf, size);
+
+ cookie\->offset += size;
+ if (cookie\->offset > cookie\->endpos)
+ cookie\->endpos = cookie\->offset;
+
+ return size;
+}
+
+ssize_t
+memfile_read(void *c, char *buf, size_t size)
+{
+ ssize_t xbytes;
+ struct memfile_cookie *cookie = c;
+
+ /* Fetch minimum of bytes requested and bytes available */
+
+ xbytes = size;
+ if (cookie\->offset + size > cookie\->endpos)
+ xbytes = cookie\->endpos \- cookie\->offset;
+ if (xbytes < 0) /* offset may be past endpos */
+ xbytes = 0;
+
+ memcpy(buf, cookie\->buf + cookie\->offset, xbytes);
+
+ cookie\->offset += xbytes;
+ return xbytes;
+}
+
+int
+memfile_seek(void *c, off64_t *offset, int whence)
+{
+ off64_t new_offset;
+ struct memfile_cookie *cookie = c;
+
+ if (whence == SEEK_SET)
+ new_offset = *offset;
+ else if (whence == SEEK_END)
+ new_offset = cookie\->endpos + *offset;
+ else if (whence == SEEK_CUR)
+ new_offset = cookie\->offset + *offset;
+ else
+ return \-1;
+
+ if (new_offset < 0)
+ return \-1;
+
+ cookie\->offset = new_offset;
+ *offset = new_offset;
+ return 0;
+}
+
+int
+memfile_close(void *c)
+{
+ struct memfile_cookie *cookie = c;
+
+ free(cookie\->buf);
+ cookie\->allocated = 0;
+ cookie\->buf = NULL;
+
+ return 0;
+}
+
+int
+main(int argc, char *argv[])
+{
+ cookie_io_functions_t memfile_func = {
+ .read = memfile_read,
+ .write = memfile_write,
+ .seek = memfile_seek,
+ .close = memfile_close
+ };
+ FILE *stream;
+ struct memfile_cookie mycookie;
+ ssize_t nread;
+ long p;
+ int j;
+ char buf[1000];
+
+ /* Set up the cookie before calling fopencookie() */
+
+ mycookie.buf = malloc(INIT_BUF_SIZE);
+ if (mycookie.buf == NULL) {
+ perror("malloc");
+ exit(EXIT_FAILURE);
+ }
+
+ mycookie.allocated = INIT_BUF_SIZE;
+ mycookie.offset = 0;
+ mycookie.endpos = 0;
+
+ stream = fopencookie(&mycookie,"w+", memfile_func);
+ if (stream == NULL) {
+ perror("fopencookie");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Write command\-line arguments to our file */
+
+ for (j = 1; j < argc; j++)
+ if (fputs(argv[j], stream) == EOF) {
+ perror("fputs");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Read two bytes out of every five, until EOF */
+
+ for (p = 0; ; p += 5) {
+ if (fseek(stream, p, SEEK_SET) == \-1) {
+ perror("fseek");
+ exit(EXIT_FAILURE);
+ }
+ nread = fread(buf, 1, 2, stream);
+ if (nread == \-1) {
+ perror("fread");
+ exit(EXIT_FAILURE);
+ }
+ if (nread == 0) {
+ printf("Reached end of file\en");
+ break;
+ }
+
+ printf("/%.*s/\en", nread, buf);
+ }
+
+ exit(EXIT_SUCCESS);
+}
+.fi
+.SH 関連項目
+\fBfclose\fP(3), \fBfmemopen\fP(3), \fBfopen\fP(3), \fBfseek\fP(3)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.78 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
--- /dev/null
+.\" Copyright (c) 1992, 1993, 1994
+.\" The Regents of the University of California. All rights reserved.
+.\" and Copyright (C) 2008, 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.\" %%%LICENSE_START(BSD_3_CLAUSE_UCB)
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 4. Neither the name of the University nor the names of its contributors
+.\" may be used to endorse or promote products derived from this software
+.\" without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\" %%%LICENSE_END
+.\"
+.\" @(#)symlink.7 8.3 (Berkeley) 3/31/94
+.\" $FreeBSD: src/bin/ln/symlink.7,v 1.30 2005/02/13 22:25:09 ru Exp $
+.\"
+.\" 2008-06-11, mtk, Taken from FreeBSD 6.2 and heavily edited for
+.\" specific Linux details, improved readability, and man-pages style.
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH SYMLINK 7 2014\-04\-06 Linux "Linux Programmer's Manual"
+.SH 名前
+symlink \- シンボリックリンクの取り扱い
+.SH 説明
+シンボリックリンクは他のファイルへのポインタとして振る舞うファイルである。
+その挙動を理解するには、まずハードリンクがどのように機能するかを理解しておかなければならない。
+
+あるファイルへのハードリンクは、 元々のファイルと区別することができない。 なぜなら、
+ハードリンクは元々のファイル名の裏にあるオブジェクトへの参照だからである。 (より正確には、 あるファイルへのハードリンクはそれぞれ同じ \fIinode
+番号\fP への参照である。 inode 番号は inode テーブルへのインデックスで、 inode
+テーブルはファイルシステム上のすべてのファイルについてのメタデータを保持している。 \fBstat\fP(2) 参照。)
+ファイルへの変更は、ファイルの参照に使用された名前とは独立に行われる。 ハードリンクはディレクトリを参照することはできない
+(これはファイルシステムツリー内でループが発生する可能性を防止するためであり、 ループが発生すると、 多くのプログラムが混乱してしまうことだろう)。
+また、 ハードリンクは異なるファイルシステム上のファイルを参照することもできない (inode
+番号はファイルシステムをまたがると一意ではないからである)。
+
+シンボリックリンクは特別な種類のファイルで、 ファイルの内容はそのリンクの参照先の別のファイルのパス名を示す文字列である (シンボリックリンクの内容は
+\fBreadlink\fP(2) を使って読むことができる)。 言い換えると、 シンボリックリンクは別の名前へのポインタであり、
+ファイルの裏にあるオブジェクトへのポインタではない。 この理由から、
+シンボリックリンクではディレクトリへの参照やファイルシステム境界を越える参照を行うことができる。
+
+シンボリックリンクが参照する先のパス名が存在しないといけないという要件はない。 存在しないパス名を参照するシンボリックリンクは「壊れた
+(dangling) リンク」と呼ばれる。
+
+シンボリックリンクとその参照先のオブジェクトは一つのファイルシステムの名前空間内に共存するので、
+リンクそのものと参照先のオブジェクトの間で混乱が生じる可能性がある。 かなり昔からあるシステムでは、
+コマンドやシステムコールはいくらかアドホックな方法の独自のリンクの辿り方の決まり事を採用している。 ここでは、 Linux
+や他のシステムで実装されている、 もっと広く使われている方法のルールについて概要を説明する。 サイト固有のアプリケーションもこれらのルールに準拠し、
+可能な限りユーザインターフェースが一貫したものになるようにすることが重要である。
+.SS シンボリックリンクの所有権、アクセス許可、タイムスタンプ
+既存のシンボリックリンクの所有者とグループは \fBlchown\fP(2) を使って変更することができる。 シンボリックリンクの所有権が問題となる場面は、
+スティッキービット (\fBstat\fP(2) 参照) がセットされたディレクトリで、 そのリンクの削除や名前の変更を行おうとしている場合だけである。
+
+シンボリックリンクの最終アクセス時刻と最終修正時刻は \fButimensat\fP(2) や \fBlutimes\fP(3) で変更できる。
+
+.\" Linux does not currently implement an lchmod(2).
+.\"
+.\" The
+.\" 4.4BSD
+.\" system differs from historical
+.\" 4BSD
+.\" systems in that the system call
+.\" .BR chown (2)
+.\" has been changed to follow symbolic links.
+.\" The
+.\" .BR lchown (2)
+.\" system call was added later when the limitations of the new
+.\" .BR chown (2)
+.\" became apparent.
+Linux では、シンボリックリンクのアクセス許可 (permission) はどの操作でも使用されない。 アクセス許可は常に 0777
+(すべてのユーザカテゴリにおいて読み出し、書き込み、実行が可能) で、変更できない。
+.SS シンボリックリンクを参照するファイルディスクリプタを取得する
+\fBopen\fP(2) に \fBO_PATH\fP と \fBO_NOFOLLOW\fP
+の両方のフラグを指定すると、ファイルディスクリプターが得られる。このファイルディスクリプターは \fBfstatat\fP(2),
+\fBfchownat\fP(2), \fBfchmodat\fP(2), \fBlinkat\fP (2), \fBreadlinkat\fP(2) などのシステムコールの
+\fIdirfd\fP 引き数として渡して、 (シンボリックリンクが参照するファイルではなく) シンボリックリンク自身に対する操作を行うことができる。
+
+デフォルトでは (すなわち \fBAT_SYMLINK_FOLLOW\fP フラグが指定されなかった場合)、 \fBname_to_handle_at\fP(2)
+がシンボリックリンクに適用された場合、 (シンボリックリンクが参照するファイルではなく) シンボリックリンクへのハンドルが返される。 それ以降の
+\fBopen_by_handle_at\fP(2) で \fBO_PATH\fP フラグを指定することで、 (シンボリックリンクが参照するファイルではなく)
+シンボリックリンクに対するファイルディスクリプターを得ることができる。 繰り返しになるが、 このファイルディスクリプターを上述のシステムコールで使用し、
+シンボリックリンク自身に操作を行うことができる。
+.SS システムコールやコマンドによるシンボリックリンクの取り扱い
+シンボリックリンクは、 リンク自身に対する操作か、 リンクが参照するオブジェクトに対する操作のいずれかとして扱われる。 後者の場合、
+アプリケーションやシステムコールはリンクを\fI辿る (follow)\fPと呼ばれる。 シンボリックリンクは他のシンボリックリンクを参照することもできる。
+この場合、 シンボリックリンクでないオブジェクトが見つかるか、 存在しないファイルを参照するシンボリックリンクが見つかるか、 ループが検出されるまで、
+リンクの展開が行われる。 (ループの検出は辿ることができるリンクの数に上限を設けることで行われる。 この上限を超過した場合はエラーとなる。)
+
+3 つの領域に分けて議論する必要がある。以下の 3 つである。
+.IP 1. 3
+システムコールのファイル名引き数としてシンボリックリンクが使用される場合。
+.IP 2.
+ファイルツリーを辿っていないユーティリティーのコマンドライン引き数としてシンボリックリンクが指定される場合。
+.IP 3.
+ファイルツリーを辿っているユーティリティーがシンボリックリンクを見つけた場合 (コマンドラインで指定される場合もあれば、
+ファイル階層を辿っている途中で遭遇する場合もある)。
+.SS システムコール
+最初の領域は、システムコールのファイル名引き数としてシンボリックリンクが使用される場合である。
+
+以下に述べる場合を除くと、 すべてのシステムコールはシンボリックリンクを辿る。 例えば、 \fIafile\fP
+という名前のファイルを指しているシンボリックリンク \fIslink\fP があったとすると、 システムコール \fIopen("slink" ...\&)\fP
+はファイル \fIafile\fP を参照するファイルディスクリプタを返す。
+
+リンクを辿らず、シンボリックリンク自身に対して操作を行うシステムコールもある。 このようなシステムコールとしては、 \fBlchown\fP(2),
+\fBlgetxattr\fP(2), \fBllistxattr\fP(2), \fBlremovexattr\fP(2), \fBlsetxattr\fP(2),
+\fBlstat\fP(2), \fBreadlink\fP(2), \fBrename\fP(2), \fBrmdir\fP(2), \fBunlink\fP(2) がある。
+
+.\" Maybe one day: .BR fchownat (2)
+他のいくつかのシステムコールは、指定された場合にのみシンボリックリンクを辿る。 これらのシステムコールとしては、 \fBfaccessat\fP(2),
+\fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2), \fBname_to_handle_at\fP(2),
+\fBopen\fP(2), \fBopenat\fP(2), \fBopen_by_handle_at\fP(2), \fButimensat\fP(2) がある。
+詳細はそれぞれのマニュアルページを参照してほしい。 \fBremove\fP(3) は \fBunlink\fP(2) の別名なので、
+このライブラリ関数もシンボリックリンクを辿らない。 \fBrmdir\fP(2) がシンボリックリンクに対して行われた場合、その呼び出しはエラー
+\fBENOTDIR\fP で失敗する。
+
+\fBlink\fP(2) については特別に議論が必要である。 POSIX.1\-2001 では \fBlink\fP(2) は \fIoldpath\fP
+がシンボリックリンクであればこれを展開するように規定している。 しかしながら、 Linux はシンボリックリンクを展開しない。 (デフォルトでは
+Solaris も同じだが、 適切なコンパイラーオプションを指定することで POSIX.1\-2001 で規定された動作をさせることができる。)
+今後のバージョンの POSIX.1 では、どちらの動作の実装も認められるように規定が変更される。
+.SS ファイルツリーを辿らないコマンド
+二つ目の領域は、 ファイルツリーを辿らないコマンドの、 コマンドライン引き数のファイル名としてシンボリックリンクが指定される場合である。
+
+以下に述べる場合を除くと、 コマンドはコマンドライン引き数で指定された名前のシンボリックリンクを辿る。 例えば、 \fIafile\fP
+という名前のファイルを指しているシンボリックリンク \fIslink\fP があったとすると、 コマンド \fIcat slink\fP は \fIafile\fP
+の内容を表示することになる。
+
+大事な点として意識しておくべきなのは、 このルールが適用されるコマンドの中には、
+オプション次第ではファイルツリーを辿る場合があるコマンドもあるということである。 例えば、 コマンド \fIchown file\fP
+はこのルールに含まれるが、 コマンド \fIchown\ \-R file\fP はツリーを辿る動作をするのであてはまらない (後者の場合は、3
+つ目の領域に該当する)。
+
+シンボリックリンクを辿るのではなく、 コマンドがシンボリックリンク自身に対して操作を行うことを明示的に指示したい場合、 例えば、 \fIchown
+slink\fP で \fIslink\fP がシンボリックリンクかどうかに関わらず、 \fIslink\fP のファイル自身の所有権を変更したい場合は、 \fI\-h\fP
+オプションを使用すべきである。 上記の例では、 \fIchown root slink\fP は \fIslink\fP が参照するファイルの所有権を変更するが、
+\fIchown\ \-h root slink\fP は \fIslink\fP 自身の所有権を変更する。
+
+このルールにはいくつかの例外がある。
+.IP * 2
+コマンド \fBmv\fP(1) と \fBrm\fP(1) は引き数で指定された名前のシンボリックリンクを辿らないが、
+それぞれシンボリックリンク自身の名前変更と削除を行おうとする。 (シンボリックリンクが相対パスでファイルを参照している場合、
+そのシンボリックリンクを別のディレクトリに移動すると、動かなくなることが非常によくある。 移動の結果、 パスが正しくないものになってしまうからである。)
+.IP *
+\fBls\fP(1) コマンドもこのルールの例外である。 昔からあるシステムとの互換性のため (\fBls\fP(1) がツリーを辿らない場合、つまり \fI\-R\fP
+オプションが指定されなかった場合)、 \fBls\fP(1) コマンドはオプション \fI\-H\fP か \fI\-L\fP が指定された場合、もしくはオプション
+\fI\-F\fP, \fI\-d\fP, \fI\-l\fP が指定されなかった場合、 引き数として指定されたシンボリックリンクを辿る。 (\fBls\fP(1) コマンドは、
+ファイルツリーを辿らない場合であっても、 オプション \fI\-H\fP と \fI\-L\fP がその動作に影響を与える唯一のコマンドである。)
+.IP *
+.\"
+.\"The 4.4BSD system differs from historical 4BSD systems in that the
+.\".BR chown (1)
+.\"and
+.\".BR chgrp (1)
+.\"commands follow symbolic links specified on the command line.
+\fBfile\fP(1) コマンドもこのルールの例外である。 \fBfile\fP(1) コマンドは、
+デフォルトでは引き数で指定されたシンボリックリンクを辿らない。 \fBfile\fP(1) コマンドは、 \fI\-L\fP オプションが指定された場合、
+引き数で指定されたシンボリックリンクを辿る。
+.SS ファイルツリーを辿るコマンド
+次のコマンドは指定された場合もしくは常にファイルツリーを辿る: \fBchgrp\fP(1), \fBchmod\fP(1), \fBchown\fP(1),
+\fBcp\fP(1), \fBdu\fP(1), \fBfind\fP(1), \fBls\fP(1), \fBpax\fP(1), \fBrm\fP(1), \fBtar\fP(1)。
+
+重要なのは、 ファイルツリーを辿っている際に見つかったシンボリックリンクにも、 コマンドライン引き数として渡されたシンボリックリンクにも、
+以下のルールが等しく適用される点である。
+
+「1 つ目のルール」は、 ディレクトリ以外のファイルを参照するシンボリックリンクに適用される。
+シンボリックリンクに適用される操作はシンボリックリンク自身に行われるが、 そうでない場合はリンクは無視される。
+
+コマンド \fIrm\ \-r slink directory\fP は \fIslink\fP を削除するとともに、
+ファイルツリーを辿る途中で見つけたシンボリックリンクも削除する。 シンボリックリンクは削除できるからである。 \fBrm\fP(1) が \fIslink\fP
+が参照するファイルに影響をおよぼすことはない。
+
+「2 つ目のルール」は、 ディレクトリを参照するシンボリックリンクに適用される。 デフォルトでは、 ディレクトリを参照するシンボリックリンクを辿らない。
+この動作はしばしば「物理的な」ツリー探索 ("physical" walk) と呼ばれる。 これに対して
+(ディレクトリを参照するシンボリックリンクを辿る場合は) 「論理的な」ツリー探索 ("logical" walk) と呼ばれる。
+
+一貫性を持たせるため、ファイルツリーを辿るコマンドが可能な限り従っている慣習がいくつかある。
+.IP * 2
+\fI\-H\fP ("half\-logical") フラグを指定すると、 参照先のファイル種別に関わらず、
+コマンドにコマンドラインで指定されたシンボリックリンクを辿らせることができる。 このフラグは、
+コマンドラインの名前空間を論理的な名前空間のように見せるためのものである。 (常にファイルツリーを辿るわけではないコマンドでは、 \fI\-R\fP
+フラグを一緒に指定しない限り、 \fI\-H\fP フラグは無視される点に注意。)
+
+例えば、 コマンド \fIchown\ \-HR user slink\fP は \fIslink\fP が指すファイルを頂点とするファイル階層を辿る。 \fI\-H\fP
+は上記で説明した \fI\-h\fP フラグとは同じではないことに注意。 \fI\-H\fP フラグを指定すると、 アクションを実行する場合でも、
+ツリーを辿る場合でも、 コマンドラインで指定されたシンボリックリンクの解決 (dereference) を行う。
+ユーザーがシンボリックリンクが指すファイル名を指定したのと同じように見える。
+.IP *
+\fI\-L\fP ("logical") フラグを指定すると、 参照先のファイル種別に関わらず、 コマンドが、
+コマンドラインで指定された名前のシンボリックリンクも、 ファイルツリーを辿る際に見つけたシンボリックリンクも辿るようになる。 このフラグは、
+名前空間全体を論理的な名前空間のように見せるためのものである。 (常にファイルツリーを辿るわけではないコマンドでは、 \fI\-R\fP
+フラグを一緒に指定しない限り、 \fI\-L\fP フラグは無視される点に注意。)
+
+例えば、 コマンド \fIchown\ \-LR user slink\fP は \fIslink\fP が参照するファイルの所有者を変更する。
+\fIslink\fP がディレクトリを参照する場合、 \fBchown\fP はそのシンボリックリンクが参照するディレクトリを頂点とするファイル階層を辿る。
+また、 \fBchown\fP が辿るファイルツリー内でシンボリックリンクが見つかった場合、 \fIslink\fP と同じように処理される。
+.IP *
+\fI\-P\fP ("physical") フラグを指定すると、 コマンドはデフォルトの動作をするようになる。
+このフラグは名前空間全体を物理的な名前空間のように見せるためのものである。
+.PP
+デフォルトでファイルツリーを辿らないコマンドでは、 \fI\-R\fP フラグが同時に指定されなかった場合、 フラグ \fI\-H\fP, \fI\-L\fP, \fI\-P\fP
+は無視される。 また、 \fI\-H\fP, \fI\-L\fP, \fI\-P\fP は複数回同時に指定できるが、 最後に指定されたオプションでコマンドの動作が決定される。
+この動作は、 コマンドのエイリアスにある動作を指定しておいて、 コマンドラインでその動作を上書きできるようにするためである。
+
+コマンド \fBls\fP(1) と \fBrm\fP(1) には、 これらのルールに対する例外がある。
+.IP * 2
+\fBrm\fP(1) コマンドは、 参照先のファイルではなく、シンボリックリンクに対して操作を行う。 したがって、 シンボリックリンクを辿ることはない。
+\fBrm\fP(1) コマンドはオプション \fI\-H\fP, \fI\-L\fP, \fI\-P\fP をサポートしていない。
+.IP *
+古いシステムとの互換性を持たせるため、 \fBls\fP(1) コマンドは少し違った動作をする。 オプション \fI\-F\fP, \fI\-d\fP, \fI\-l\fP
+を指定した場合、 \fBls\fP(1) はコマンドラインで指定されたシンボリックリンクを辿る。 \fI\-L\fP フラグが指定された場合、
+コマンドラインで指定された場合でも、 ファイルツリーを辿る際に見つかった場合でも、 ファイル種別に関わらず、 \fBls\fP(1)
+はすべてのシンボリックリンクを辿る。
+.SH 関連項目
+\fBchgrp\fP(1), \fBchmod\fP(1), \fBfind\fP(1), \fBln\fP(1), \fBls\fP(1), \fBmv\fP(1),
+\fBrm\fP(1), \fBlchown\fP(2), \fBlink\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2),
+\fBrename\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fButimensat\fP(2),
+\fBlutimes\fP(3), \fBpath_resolution\fP(7)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.78 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
# pagename,#complete,#remaining,#all
-fopencookie.3,65,33,98
open_by_handle_at.2,128,16,144
-symlink.7,63,8,71
○:LDP man-pages:3.78:2013/06/21:fmtmsg:3:2015/01/24::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.78:2000/10/15:fnmatch:3:2015/01/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.78:2012/04/22:fopen:3:2015/01/24::amotoki@gmail.com:Akihiro MOTOKI:
-×:LDP man-pages:3.78:2015/01/22:fopencookie:3:::::
+○:LDP man-pages:3.78:2015/01/22:fopencookie:3:2015/01/24::amotoki@gmail.com:Akihiro Motoki:
＠:LDP man-pages:3.78:2014/08/19:forkpty:3:openpty:3:
○:LDP man-pages:3.78:2014/05/28:fpathconf:3:2015/01/24::nakano@apm.seikei.ac.jp:NAKANO Takeo:
○:LDP man-pages:3.78:2013/08/06:fpclassify:3:2015/01/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.78:2014/01/15:standards:7:2015/01/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.78:2000/11/16:suffixes:7:2015/01/24::ysato@h4.dion.ne.jp:Yuichi SATO:
○:LDP man-pages:3.78:2014/09/21:svipc:7:2015/01/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-×:LDP man-pages:3.78:2014/04/06:symlink:7:::::
+○:LDP man-pages:3.78:2014/04/06:symlink:7:2015/01/24::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.78:2015/01/10:tcp:7:2015/01/24::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.78:2013/02/12:termio:7:2015/01/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.78:2012/10/28:time:7:2015/01/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
<TR><TD>cpuid.4</TD><TD>13/24</TD><TD>45.83</TD></TR>
<TR><TD>hpsa.4</TD><TD>23/57</TD><TD>59.65</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>stdio</B></TD></TR>
-<TR><TD>fopencookie.3</TD><TD>33/98</TD><TD>66.33</TD></TR>
<TR class="over80"><TD>open_by_handle_at.2</TD><TD>16/144</TD><TD>88.89</TD></TR>
-<TR class="over80"><TD>symlink.7</TD><TD>8/71</TD><TD>88.73</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>stdlib</B></TD></TR>
<TR><TD>getauxval.3</TD><TD>34/86</TD><TD>60.47</TD></TR>
<TR><TD>vdso.7</TD><TD>139/184</TD><TD>24.46</TD></TR>
-<TR><TD COLSPAN=3>Total 48 pages</TD></TR>
+<TR><TD COLSPAN=3>Total 46 pages</TD></TR>
</TABLE>
</BODY></HTML>
OSDN Git Service
