A file test, where X is one of the letters listed below. This unary operator takes one argument, either a filename, a filehandle, or a dirhandle, and tests the associated file to see if something is true about it. If the argument is omitted, tests $_, except for -t, which tests STDIN. Unless otherwise documented, it returns 1 for true and '' for false. If the file doesn't exist or can't be examined, it returns undef and sets $! (errno). With the exception of the -l test they all follow symbolic links because they use stat() and not lstat() (so dangling symlinks can't be examined and will therefore report failure).

X は以下にあげる文字で、ファイルテストを行ないます。 この単項演算子は、ファイル名かファイルハンドルを唯一の引数として動作し、 「あること」について真であるか否かを判定した結果を返します。 引数が省略されると、-t では STDIN を調べますが、その他は $_ を調べます。 特に記述されていなければ、真として 1 を返し、偽として '' を返します。 ファイルが存在しないか、テスト出来なければ、undef を返し、 $! (errno) を設定します。 -l テストを例外として、これら全てはシンボリックリンクに従います; lstat() ではなく stat() を使っているからです (従って壊れたシンボリックリンクは検査されず、失敗が報告されます)。

Despite the funny names, precedence is the same as any other named unary operator. The operator may be any of:

みかけは変わっていますが、優先順位は名前付き単項演算子と同じで、 他の単項演算子と同じく、引数を括弧で括ることもできます。 演算子には以下のものがあります:

    -r  File is readable by effective uid/gid.
    -w  File is writable by effective uid/gid.
    -x  File is executable by effective uid/gid.
    -o  File is owned by effective uid.
    -r  ファイルが実効 uid/gid で読み出し可。
    -w  ファイルが実効 uid/gid で書き込み可。
    -x  ファイルが実効 uid/gid で実行可。
    -o  ファイルが実効 uid の所有物。
    -R  File is readable by real uid/gid.
    -W  File is writable by real uid/gid.
    -X  File is executable by real uid/gid.
    -O  File is owned by real uid.
    -R  ファイルが実 uid/gid で読み出し可。
    -W  ファイルが実 uid/gid で書き込み可。
    -X  ファイルが実 uid/gid で実行可。
    -O  ファイルが実 uid の所有物。
    -e  File exists.
    -z  File has zero size (is empty).
    -s  File has nonzero size (returns size in bytes).
    -e  ファイルが存在する。
    -z  ファイルの大きさがゼロ(空)。
    -s  ファイルの大きさがゼロ以外 (バイト単位での大きさを返す)。
    -f  File is a plain file.
    -d  File is a directory.
    -l  File is a symbolic link (false if symlinks aren't
        supported by the file system).
    -p  File is a named pipe (FIFO), or Filehandle is a pipe.
    -S  File is a socket.
    -b  File is a block special file.
    -c  File is a character special file.
    -t  Filehandle is opened to a tty.
    -f  ファイルは通常ファイル。
    -d  ファイルはディレクトリ。
    -l  ファイルはシンボリックリンク(ファイルシステムが非対応なら偽)。
    -p  ファイルは名前付きパイプ (FIFO) またはファイルハンドルはパイプ。
    -S  ファイルはソケット。
    -b  ファイルはブロック特殊ファイル。
    -c  ファイルはキャラクタ特殊ファイル。
    -t  ファイルハンドルは tty にオープンされている。
    -u  File has setuid bit set.
    -g  File has setgid bit set.
    -k  File has sticky bit set.
    -u  ファイルの setuid ビットがセットされている。
    -g  ファイルの setgid ビットがセットされている。
    -k  ファイルの sticky ビットがセットされている。
    -T  File is an ASCII or UTF-8 text file (heuristic guess).
    -B  File is a "binary" file (opposite of -T).
    -T  ファイルは ASCII または UTF-8 テキストファイル (発見的に推測します)。
    -B  ファイルは「バイナリ」ファイル (-T の反対)。
    -M  Script start time minus file modification time, in days.
    -A  Same for access time.
    -C  Same for inode change time (Unix, may differ for other
    -M  スクリプト実行開始時刻からファイル修正時刻を引いたもの(日単位)。
    -A  同様にアクセスがあってからの日数。
    -C  同様に(Unix では) inode が変更されてからの日数(それ以外の



    while (<>) {
        next unless -f $_;  # ignore specials

Note that -s/a/b/ does not do a negated substitution. Saying -exp($foo) still works as expected, however: only single letters following a minus are interpreted as file tests.

-s/a/b は、置換演算 (s///) の符号反転ではありません。 しかし、-exp($foo) は期待どおりに動作します; しかし、マイナス記号の後に 英字が 1 字続くときにのみ、ファイルテストと解釈されます。

These operators are exempt from the "looks like a function rule" described above. That is, an opening parenthesis after the operator does not affect how much of the following code constitutes the argument. Put the opening parentheses before the operator to separate it from code that follows (this applies only to operators with higher precedence than unary operators, of course):

これらの演算子は上述の「関数のように見えるルール」から免除されます。 つまり、演算子の後の開きかっこは、引き続くコードのどこまでが引数を 構成するかに影響を与えません。 演算子を引き続くコードから分離するには、演算子の前に開きかっこを 置いてください (これはもちろん、単項演算子より高い優先順位を持つ 演算子にのみ適用されます):

    -s($file) + 1024   # probably wrong; same as -s($file + 1024)
    (-s $file) + 1024  # correct

The interpretation of the file permission operators -r, -R, -w, -W, -x, and -X is by default based solely on the mode of the file and the uids and gids of the user. There may be other reasons you can't actually read, write, or execute the file: for example network filesystem access controls, ACLs (access control lists), read-only filesystems, and unrecognized executable formats. Note that the use of these six specific operators to verify if some operation is possible is usually a mistake, because it may be open to race conditions.

ファイルのパーミッション演算子 -r, -R, -w, -W, -x, -X の解釈は、ファイルのモードとユーザの実効/実 uid と 実効/実 gid のみから判断されます。 実際にファイルが読めたり、書けたり、実行できたりするためには、 別の条件が必要かもしれません: 例えば、ネットワークファイルシステムアクセスコントロール、 ACL(アクセスコントロールリスト)、読み込み専用ファイルシステム、 認識できない実行ファイルフォーマット、などです。 これらの 6 つの演算子を、特定の操作が可能かどうかを確認するために使うのは 通常は誤りであることに注意してください; なぜなら、これらは競合条件を 招きやすいからです。

Also note that, for the superuser on the local filesystems, the -r, -R, -w, and -W tests always return 1, and -x and -X return 1 if any execute bit is set in the mode. Scripts run by the superuser may thus need to do a stat to determine the actual mode of the file, or temporarily set their effective uid to something else.

ローカルファイルシステムのスーパーユーザには、 -r, -R, -w, -W に対して、常に 1 が返り、モード中の いずれかの実行許可ビットが立っていれば、-x, -X にも 1 が 返ることにも注意してください。 スーパーユーザが実行するスクリプトでは、ファイルのモードを調べるためには、 stat を行なうか、実効 uid を一時的に別のものにする 必要があるでしょう。

If you are using ACLs, there is a pragma called filetest that may produce more accurate results than the bare stat mode bits. When under use filetest 'access', the above-mentioned filetests test whether the permission can(not) be granted using the access(2) family of system calls. Also note that the -x and -X tests may under this pragma return true even if there are no execute permission bits set (nor any extra execute permission ACLs). This strangeness is due to the underlying system calls' definitions. Note also that, due to the implementation of use filetest 'access', the _ special filehandle won't cache the results of the file tests when this pragma is in effect. Read the documentation for the filetest pragma for more information.

ACL を使っている場合は、生の stat モードビットより 精度の高い結果を作成する filetest プラグマがあります。 use filetest 'access' とした場合、上述したファイルテストは システムコールの access(2) ファミリーを使って権限が与えられているか どうかをテストします。 また、このプラグマが指定されている場合、-x-X テストは たとえ実行許可ビット(または追加の実行許可 ACL)がセットされていない 場合でも真を返すことに注意してください。 この挙動は使用するシステムコールの定義によるものです。 use filetest 'access' の実装により、このプラグマが有効の場合は _ 特殊ファイルハンドルはファイルテストの結果をキャッシュしないことに 注意してください。 さらなる情報については filetest プラグマのドキュメントを 参照してください。

The -T and -B tests work as follows. The first block or so of the file is examined to see if it is valid UTF-8 that includes non-ASCII characters. If so, it's a -T file. Otherwise, that same portion of the file is examined for odd characters such as strange control codes or characters with the high bit set. If more than a third of the characters are strange, it's a -B file; otherwise it's a -T file. Also, any file containing a zero byte in the examined portion is considered a binary file. (If executed within the scope of a use locale which includes LC_CTYPE, odd characters are anything that isn't a printable nor space in the current locale.) If -T or -B is used on a filehandle, the current IO buffer is examined rather than the first block. Both -T and -B return true on an empty file, or a file at EOF when testing a filehandle. Because you have to read a file to do the -T test, on most occasions you want to use a -f against the file first, as in next unless -f $file && -T $file.

ファイルテスト -T-B の動作原理は、次のようになっています。 ファイルの最初の数ブロックを調べて、非 ASCII 文字を含む妥当な UTF-8 かどうかを 調べます。 もしそうなら、それは -T ファイルです。 さもなければ、ファイルの同じ位置から、変わった制御コードや 上位ビットがセットされているような、通常のテキストには現れない文字を探します。 三分の一以上がおかしな文字なら、それは -B ファイルでです; さもなければ -T ファイルです。 また、調べた位置にヌル文字が含まれるファイルも、バイナリファイルと みなされます。 (LC_CTYPE を含む use locale のスコープの中で実行されると、 おかしな文字というのは現在のロケールで表示可能でもスペースでもないものです。) -T-B をファイルハンドルに対して用いると、 最初のブロックを調べる代わりに、IO バッファを調べます。 調べたファイルの中身が何もないときや、 ファイルハンドルを調べたときに EOF に達して いたときには、-T-B も「真」を返します。 -T テストをするためにはファイルを読み込まないといけないので、 たいていは next unless -f $file && -T $file というような形で まず調べたいファイルに対して -f を使いたいはずです。

If any of the file tests (or either the stat or lstat operator) is given the special filehandle consisting of a solitary underline, then the stat structure of the previous file test (or stat operator) is used, saving a system call. (This doesn't work with -t, and you need to remember that lstat and -l leave values in the stat structure for the symbolic link, not the real file.) (Also, if the stat buffer was filled by an lstat call, -T and -B will reset it with the results of stat _). Example:

どのファイルテスト (あるいは、statlstat) 演算子にも、 下線だけから成る特別なファイルハンドルを与えると、 前回のファイルテスト (や stat 演算子) の stat 構造体が使われ、システムコールを省きます。 (-t には使えませんし、lstat-l は 実ファイルではなく、シンボリックリンクの情報を stat 構造体に残すことを 覚えておく必要があります。) (また、stat バッファが lstat 呼び出しで埋まった場合、 -T-B の結果は stat _ の結果でリセットされます。 例:

    print "Can do.\n" if -r $x || -w _ || -x _;

    print "Readable\n" if -r _;
    print "Writable\n" if -w _;
    print "Executable\n" if -x _;
    print "Setuid\n" if -u _;
    print "Setgid\n" if -g _;
    print "Sticky\n" if -k _;
    print "Text\n" if -T _;
    print "Binary\n" if -B _;

As of Perl 5.10.0, as a form of purely syntactic sugar, you can stack file test operators, in a way that -f -w -x $file is equivalent to -x $file && -w _ && -f _. (This is only fancy syntax: if you use the return value of -f $file as an argument to another filetest operator, no special magic will happen.)

Perl 5.10.0 から、純粋にシンタックスシュガーとして、ファイルテスト演算子を スタックさせることができるので、-f -w -x $file-x $file && -w _ && -f _ と等価です。 (これは文法上だけの話です; もし -f $file の返り値を他のファイルテスト 演算子の引数として使う場合は、何の特別なことも起きません。)

Portability issues: "-X" in perlport.

移植性の問題: "-X" in perlport

To avoid confusing would-be users of your code with mysterious syntax errors, put something like this at the top of your script:

あなたのコードのユーザーが不思議な文法エラーで混乱することを 避けるために、スクリプトの先頭に以下のようなことを書いてください:

    use v5.10;  # so filetest ops can stack