-X

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, or
the undefined value if the file doesn't exist. Despite the funny
names, precedence is the same as any other named unary operator. The
operator may be any of:

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.

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.

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 the usefiletest'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 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 usefiletest'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.

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.

The -T
and -B
switches work as follows. The first block or so of the
file is examined for odd characters such as strange control codes or
characters with the high bit set. If too many strange characters (>30%)
are found, it's a -B
file; otherwise it's a -T
file. Also, any file
containing a zero byte in the first block is considered a binary file. 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
.

If any of the file tests (or either the stat or lstat operators) are 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:

As of Perl 5.9.1, 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 fancy: if you use
the return value of -f $file
as an argument to another filetest
operator, no special magic will happen.)

perldoc.perl.org - Official documentation for the Perl programming language