view release on metacpan or  search on metacpan

docs/Perl6/Spec/IO.pod  view on Meta::CPAN

    -t	Filehandle is opened to a tty.

    -u	File has setuid bit set.
    -g	File has setgid bit set.
    -k	File has sticky bit set.

    -T	File is an ASCII text file (heuristic guess).
    -B	File is a "binary" file (opposite of -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 platforms)

The interpretation of the file permission operators C<-r>, C<-R>,
C<-w>, C<-W>, C<-x>, and C<-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.  Such
reasons may be for example network filesystem access controls, ACLs
(access control lists), read-only filesystems, and unrecognized
executable formats.

Also note that, for the superuser on the local filesystems, the C<-r>,
C<-R>, C<-w>, and C<-W> tests always return 1, and C<-x> and C<-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 C<filetest> that may
produce more accurate results than the bare stat() mode bits.
When under the C<use filetest 'access'> the above-mentioned filetests
will test whether the permission can (not) be granted using the
access() family of system calls.  Also note that the C<-x> and C<-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.  Read the
documentation for the C<filetest> pragma for more information.

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

The C<-T> and C<-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 C<-B> file; otherwise it's a C<-T> file.  Also, any file
containing null in the first block is considered a binary file.  If C<-T>
or C<-B> is used on a filehandle, the current IO buffer is examined
rather than the first block.  Both C<-T> and C<-B> return true on a null
file, or a file at EOF when testing a filehandle.  Because you have to
read a file to do the C<-T> test, on most occasions you want to use a C<-f>
against the file first, as in C<next unless -f $file && -T $file>.

The return value of a test is both a boolean and a stat buffer. So you can say:

  if -r -w -x $filename {...}

Or chain tests together in OO style:
 
  if $filename.'-e'.'-x' {...}

=item chown

=item chmod LIST
X<chmod> X<permission> X<mode>

Changes the permissions of a list of files.  The first element of the
list must be the numerical mode, which should probably be an octal
number, and which definitely should I<not> be a string of octal digits:
C<0o644> is okay, C<0644> is not.  Returns the number of files
successfully changed.

    $cnt = chmod 0o755, 'foo', 'bar';
    chmod 0o755, @executables;
    $mode = '0644'; chmod $mode, 'foo';      # !!! sets mode to --w----r-T
    $mode = '0o644'; chmod $mode, 'foo';     # this is better
    $mode = 0o644;   chmod $mode, 'foo';     # this is best

=item close FILEHANDLE

Closes the file or pipe associated with the file handle, returning
true only if IO buffers are successfully flushed and closes the system
file descriptor.  Closes the currently selected filehandle if the
argument is omitted.

You don't have to close FILEHANDLE if you are immediately going to do
another C<open> on it, because C<open> will close it for you.  (See
C<open>.)  However, an explicit C<close> on an input file resets the line
counter (C<$.>), while the implicit close done by C<open> does not.

If the file handle came from a piped open, C<close> will additionally
return false if one of the other system calls involved fails, or if the
program exits with non-zero status.  (If the only problem was that the
program exited non-zero, C<$!> will be set to C<0>.)  Closing a pipe
also waits for the process executing on the pipe to complete, in case you
want to look at the output of the pipe afterwards, and
implicitly puts the exit status value of that command into C<$!>.

=item closedir

 closedir (IO::Dir $dir)  
 $dir.closedir

Closes a directory opened by C<opendir> and returns the success of that
system call.

=item connect

 my $fh = connect($hostname, 80);

Attempts to connect to a remote host and returns an IO handle if successful.
The call fails with an exception if it cannot connect.

=item fcntl

=item glob

=item ioctl

=item link

=item listen