perlfunc.pod

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· POD 代码 · 共 1,629 行 · 第 1/5 页

    -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)

Example:

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

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: 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 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. Note also that, due to
the implementation of C<use filetest 'access'>, the C<_> special
filehandle won't cache the results of the file tests when this pragma is
in effect.  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>.

If any of the file tests (or either the C<stat> or C<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 C<-t>, and you need to remember
that lstat() and C<-l> will leave values in the stat structure for the
symbolic link, not the real file.)  (Also, if the stat buffer was filled by
an C<lstat> call, C<-T> and C<-B> will reset it with the results of C<stat _>).
Example:

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

    stat($filename);
    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.9.1, as a form of purely syntactic sugar, you can stack file
test operators, in a way that C<-f -w -x $file> is equivalent to
C<-x $file && -w _ && -f _>. (This is only syntax fancy: if you use
the return value of C<-f $file> as an argument to another filetest
operator, no special magic will happen.)

=item abs VALUE
X<abs> X<absolute>

=item abs

Returns the absolute value of its argument.
If VALUE is omitted, uses C<$_>.

=item accept NEWSOCKET,GENERICSOCKET
X<accept>

Accepts an incoming socket connect, just as the accept(2) system call
does.  Returns the packed address if it succeeded, false otherwise.
See the example in L<perlipc/"Sockets: Client/Server Communication">.

On systems that support a close-on-exec flag on files, the flag will
be set for the newly opened file descriptor, as determined by the
value of $^F.  See L<perlvar/$^F>.

=item alarm SECONDS
X<alarm>
X<SIGALRM>
X<timer>

=item alarm

Arranges to have a SIGALRM delivered to this process after the
specified number of wallclock seconds has elapsed.  If SECONDS is not
specified, the value stored in C<$_> is used. (On some machines,
unfortunately, the elapsed time may be up to one second less or more
than you specified because of how seconds are counted, and process
scheduling may delay the delivery of the signal even further.)

Only one timer may be counting at once.  Each call disables the
previous timer, and an argument of C<0> may be supplied to cancel the
previous timer without starting a new one.  The returned value is the
amount of time remaining on the previous timer.

For delays of finer granularity than one second, the Time::HiRes module
(from CPAN, and starting from Perl 5.8 part of the standard
distribution) provides ualarm().  You may also use Perl's four-argument
version of select() leaving the first three arguments undefined, or you
might be able to use the C<syscall> interface to access setitimer(2) if
your system supports it. See L<perlfaq8> for details.

It is usually a mistake to intermix C<alarm> and C<sleep> calls.
(C<sleep> may be internally implemented in your system with C<alarm>)

If you want to use C<alarm> to time out a system call you need to use an
C<eval>/C<die> pair.  You can't rely on the alarm causing the system call to
fail with C<$!> set to C<EINTR> because Perl sets up signal handlers to
restart system calls on some systems.  Using C<eval>/C<die> always works,
modulo the caveats given in L<perlipc/"Signals">.

    eval {
	local $SIG{ALRM} = sub { die "alarm\n" }; # NB: \n required
	alarm $timeout;
	$nread = sysread SOCKET, $buffer, $size;
	alarm 0;
    };
    if ($@) {
	die unless $@ eq "alarm\n";   # propagate unexpected errors
    	# timed out
    }
    else {
    	# didn't
    }

For more information see L<perlipc>.

=item atan2 Y,X
X<atan2> X<arctangent> X<tan> X<tangent>

Returns the arctangent of Y/X in the range -PI to PI.

For the tangent operation, you may use the C<Math::Trig::tan>
function, or use the familiar relation:

    sub tan { sin($_[0]) / cos($_[0])  }

Note that atan2(0, 0) is not well-defined.

=item bind SOCKET,NAME
X<bind>

Binds a network address to a socket, just as the bind system call
does.  Returns true if it succeeded, false otherwise.  NAME should be a
packed address of the appropriate type for the socket.  See the examples in
L<perlipc/"Sockets: Client/Server Communication">.

=item binmode FILEHANDLE, LAYER
X<binmode> X<binary> X<text> X<DOS> X<Windows>

=item binmode FILEHANDLE

Arranges for FILEHANDLE to be read or written in "binary" or "text"
mode on systems where the run-time libraries distinguish between
binary and text files.  If FILEHANDLE is an expression, the value is
taken as the name of the filehandle.  Returns true on success,
otherwise it returns C<undef> and sets C<$!> (errno).

On some systems (in general, DOS and Windows-based systems) binmode()
is necessary when you're not working with a text file.  For the sake
of portability it is a good idea to always use it when appropriate,
and to never use it when it isn't appropriate.  Also, people can
set their I/O to be by default UTF-8 encoded Unicode, not bytes.

In other words: regardless of platform, use binmode() on binary data,
like for example images.

If LAYER is present it is a single string, but may contain multiple
directives. The directives alter the behaviour of the file handle.
When LAYER is present using binmode on text file makes sense.

If LAYER is omitted or specified as C<:raw> the filehandle is made
suitable for passing binary data. This includes turning off possible CRLF
translation and marking it as bytes (as opposed to Unicode characters).
Note that, despite what may be implied in I<"Programming Perl"> (the
Camel) or elsewhere, C<:raw> is I<not> simply the inverse of C<:crlf>
-- other layers which would affect the binary nature of the stream are
I<also> disabled. See L<PerlIO>, L<perlrun> and the discussion about the
PERLIO environment variable.

The C<:bytes>, C<:crlf>, and C<:utf8>, and any other directives of the
form C<:...>, are called I/O I<layers>.  The C<open> pragma can be used to
establish default I/O layers.  See L<open>.

I<The LAYER parameter of the binmode() function is described as "DISCIPLINE"
in "Programming Perl, 3rd Edition".  However, since the publishing of this
book, by many known as "Camel III", the consensus of the naming of this
functionality has moved from "discipline" to "layer".  All documentation
of this version of Perl therefore refers to "layers" rather than to
"disciplines".  Now back to the regularly scheduled documentation...>

To mark FILEHANDLE as UTF-8, use C<:utf8> or C<:encoding(utf8)>.
C<:utf8> just marks the data as UTF-8 without further checking,
while C<:encoding(utf8)> checks the data for actually being valid
UTF-8. More details can be found in L<PerlIO::encoding>.

In general, binmode() should be called after open() but before any I/O
is done on the filehandle.  Calling binmode() will normally flush any
pending buffered output data (and perhaps pending input data) on the
handle.  An exception to this is the C<:encoding> layer that
changes the default character encoding of the handle, see L<open>.
The C<:encoding> layer sometimes needs to be called in
mid-stream, and it doesn't flush the stream.  The C<:encoding>
also implicitly pushes on top of itself the C<:utf8> layer because
internally Perl will operate on UTF-8 encoded Unicode characters.

The operating system, device drivers, C libraries, and Perl run-time
system all work together to let the programmer treat a single
character (C<\n>) as the line terminator, irrespective of the external
representation.  On many operating systems, the native text file
representation matches the internal representation, but on some
platforms the external representation of C<\n> is made up of more than
one character.

Mac OS, all variants of Unix, and Stream_LF files on VMS use a single
character to end each line in the external representation of text (even
though that single character is CARRIAGE RETURN on Mac OS and LINE FEED
on Unix and most VMS files). In other systems like OS/2, DOS and the
various flavors of MS-Windows your program sees a C<\n> as a simple C<\cJ>,
but what's stored in text files are the two characters C<\cM\cJ>.  That
means that, if you don't use binmode() on these systems, C<\cM\cJ>
sequences on disk will be converted to C<\n> on input, and any C<\n> in
your program will be converted back to C<\cM\cJ> on output.  This is what
you want for text files, but it can be disastrous for binary files.

Another consequence of using binmode() (on some systems) is that
special end-of-file markers will be seen as part of the data stream.
For systems from the Microsoft family this means that if your binary
data contains C<\cZ>, the I/O subsystem will regard it as the end of
the file, unless you use binmode().

binmode() is not only important for readline() and print() operations,
but also when using read(), seek(), sysread(), syswrite() and tell()
(see L<perlport> for more details).  See the C<$/> and C<$\> variables
in L<perlvar> for how to manually set your input and output
line-termination sequences.

=item bless REF,CLASSNAME
X<bless>

=item bless REF

This function tells the thingy referenced by REF that it is now an object
in the CLASSNAME package.  If CLASSNAME is omitted, the current package
is used.  Because a C<bless> is often the last thing in a constructor,
it returns the reference for convenience.  Always use the two-argument
version if a derived class might inherit the function doing the blessing.
See L<perltoot> and L<perlobj> for more about the blessing (and blessings)
of objects.

Consider always blessing objects in CLASSNAMEs that are mixed case.
Namespaces with all lowercase names are considered reserved for
Perl pragmata.  Builtin types have all uppercase names. To prevent
confusion, you may wish to avoid such package names as well.  Make sure
that CLASSNAME is a true value.

See L<perlmod/"Perl Modules">.

=item break

Break out of a C<given()> block.

This keyword is enabled by the "switch" feature: see L<feature>
for more information.

=item caller EXPR
X<caller> X<call stack> X<stack> X<stack trace>

=item caller

Returns the context of the current subroutine call.  In scalar context,
returns the caller's package name if there is a caller, that is, if
we're in a subroutine or C<eval> or C<require>, and the undefined value
otherwise.  In list context, returns

    # 0         1          2
    ($package, $filename, $line) = caller;

With EXPR, it returns some extra information that the debugger uses to
print a stack trace.  The value of EXPR indicates how many call frames
to go back before the current one.

    #  0         1          2      3            4
    ($package, $filename, $line, $subroutine, $hasargs,

    #  5          6          7            8       9         10
    $wantarray, $evaltext, $is_require, $hints, $bitmask, $hinthash)
     = caller($i);

Here $subroutine may be C<(eval)> if the frame is not a subroutine
call, but an C<eval>.  In such a case additional elements $evaltext and
C<$is_require> are set: C<$is_require> is true if the frame is created by a
C<require> or C<use> statement, $evaltext contains the text of the
C<eval EXPR> statement.  In particular, for an C<eval BLOCK> statement,
$subroutine is C<(eval)>, but $evaltext is undefined.  (Note also that