Every time you use stat, lstat, or a file test in a program, Perl has to go out to the system to ask for a stat buffer on the file (that is, the return buffer from the stat system call). That means if you want to know if a file is readable and writable, you’ll ask the system twice for the same information, which isn’t likely to change in a nonhostile environment.

This looks like a waste of time,* and can be avoided. Doing a file test, stat , or lstat on the special _ filehandle (the operand being a single underscore) tells Perl to use whatever happens to be lounging around in memory from the previous file test, stat , or lstat function, rather than going out to the operating system again. Sometimes this is dangerous: a subroutine call can invoke stat without your knowledge, blowing your buffer away. If you’re careful, you can save yourself a few unneeded system calls, thereby making your program faster. Here’s that example of finding files to put on the backup tapes again, using the new tricks you’ve learned:

  my @original_files = qw/ fred barney betty wilma pebbles dino bamm-bamm /;
  my @big_old_files;                   # The ones we want to put on backup tapes
  foreach (@original_files) {
    push @big_old_files, $ _
      if (-s) > 100_000 and -A _ > 90; # More efficient than before
  }

We used the default of $_ for the first test; this is as more efficient (except perhaps for the programmer), and it gets the data from the operating system. The second test uses the magic _ filehandle. For this test, the data left around after getting the file’s size are used, which are what we want.

Testing the _ filehandle is different from allowing the operand of a file test, stat ,or lstat to default to testing $_ . Using $_ would be a fresh test each time on the current file named by the contents of $_ , but using _ saves the trouble of calling the system again. Here is another case where similar names were chosen for radically different functions.

See Appendix Q for answers to the following exercises:

1. [15] Make a program that takes a list of files named on the command line and reports for each one whether it’s readable, writable, executable, or doesn’t exist. (Hint: It may be helpful to have a function that will do all of the file tests for one file at a time.) What does it report about a file which has been chmod ’ed to 0 ? (That is, if you’re on a Unix system, use the command chmod 0 some_file  to mark that file as neither being readable, writable, nor executable.) In most shells, use a star as the argument to mean all of the normal files in the current directory. That is, you could type something like ./ex11-1 *   to ask the program for the attributes of many files at once.
   
2. [10] Make a program to identify the oldest file named on the command line and report its age in days. What does it do if the list is empty (that is, if no files are mentioned on the command line)?

* It’s more likely that, instead of having the list of files in an array as our example shows, you’ll read it directly
from the filesystem using a glob or directory handle as we will show in Chapter 12. Since you haven’t seen that yet, we’ll just start with the list and go from there.

† There’s a way to make this example more efficient as you’ll see by the end of the chapter.

* The -o and -O tests relate only to the user ID and not to the group ID.

† For advanced students, the corresponding -R, -W, -X, and -O tests use the real user or group ID, which becomes important if your program may be running set-ID. In that case, it’s generally the ID of the person
who requested running it. See any good book about advanced Unix programming for a discussion of set-ID programs.

‡ This is the case on many non-Unix filesystems but not all of the file tests are meaningful everywhere. For example, you aren’t likely to have block special files on your non-Unix system.

* This information will be somewhat different on non-Unix systems since not all keep track of the same times that Unix does. For example, on some systems, the ctime field (which the -C test looks at) is the file creation time (which Unix doesn’t keep track of), rather than the inode change time. See the perlport manpage.

† As recorded in the $^T variable, which you could update (with a statement like $^T = time;) if you needed to get the ages relative to a different starting time.

* The -t file test is an exception since that test isn’t useful with filenames (they’re never TTYs). By default, it tests STDIN.

† On a non-Unix system, stat and lstat, as well as the file tests, should return “the closest thing available.” For example, a system that doesn’t have user IDs (that is, a system that has just one “user,” in the Unix sense) might return zero for the user and group IDs as if the only user is the system administrator. If stat or lstat
fails, it will return an empty list. If the system call underlying a file test fails (or isn’t available on the given system), that test will generally return undef. See the perlport manpage for the latest about what to expect on different systems.

* The first character in that string isn’t a permission bit. It indicates the type of entry: a hyphen for an ordinary file, d for directory, or l for symbolic link, among others. The ls command determines this from the other bits past the least significant nine.