C<endnetent>, C<endprotoent>, C<endpwent>, C<endservent>, C<exec>,
C<fcntl>, C<flock>, C<fork>, C<getgrent>, C<getgrgid>, C<gethostbyname>,
C<gethostent>, C<getlogin>, C<getnetbyaddr>, C<getnetbyname>, C<getnetent>,
-C<getppid>, C<getprgp>, C<getpriority>, C<getprotobynumber>,
+C<getppid>, C<getpgrp>, C<getpriority>, C<getprotobynumber>,
C<getprotoent>, C<getpwent>, C<getpwnam>, C<getpwuid>,
C<getservbyport>, C<getservent>, C<getsockopt>, C<glob>, C<ioctl>,
C<kill>, C<link>, C<lstat>, C<msgctl>, C<msgget>, C<msgrcv>,
=item chdir EXPR
+=item chdir FILEHANDLE
+
+=item chdir DIRHANDLE
+
+=item chdir
+
Changes the working directory to EXPR, if possible. If EXPR is omitted,
changes to the directory specified by C<$ENV{HOME}>, if set; if not,
changes to the directory specified by C<$ENV{LOGDIR}>. (Under VMS, the
neither is set, C<chdir> does nothing. It returns true upon success,
false otherwise. See the example under C<die>.
+On systems that support fchdir, you might pass a file handle or
+directory handle as argument. On systems that don't support fchdir,
+passing handles produces a fatal error at run time.
+
=item chmod LIST
Changes the permissions of a list of files. The first element of the
$mode = '0644'; chmod oct($mode), 'foo'; # this is better
$mode = 0644; chmod $mode, 'foo'; # this is best
+On systems that support fchmod, you might pass file handles among the
+files. On systems that don't support fchmod, passing file handles
+produces a fatal error at run time.
+
+ open(my $fh, "<", "foo");
+ my $perm = (stat $fh)[2] & 07777;
+ chmod($perm | 0600, $fh);
+
You can also import the symbolic C<S_I*> constants from the Fcntl
module:
$cnt = chown $uid, $gid, 'foo', 'bar';
chown $uid, $gid, @filenames;
+On systems that support fchown, you might pass file handles among the
+files. On systems that don't support fchown, passing file handles
+produces a fatal error at run time.
+
Here's an example that looks up nonnumeric uids in the passwd file:
print "User: ";
to 255 (inclusive) are by default not encoded in UTF-8 Unicode for
backward compatibility reasons (but see L<encoding>).
+Negative values give the Unicode replacement character (chr(0xfffd)),
+except under the L</bytes> pragma, where low eight bits of the value
+(truncated to an integer) are used.
+
If NUMBER is omitted, uses C<$_>.
For the reverse, use L</ord>.
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<$?>.
+implicitly puts the exit status value of that command into C<$?> and
+C<${^CHILD_ERROR_NATIVE}>.
Prematurely closing the read end of a pipe (i.e. before the process
writing to it at the other end has closed it) will result in a
=item crypt PLAINTEXT,SALT
-Encrypts a string exactly like the crypt(3) function in the C library
-(assuming that you actually have a version there that has not been
-extirpated as a potential munition). This can prove useful for checking
-the password file for lousy passwords, amongst other things. Only the
-guys wearing white hats should do this.
-
-Note that L<crypt|/crypt> is intended to be a one-way function, much like
-breaking eggs to make an omelette. There is no (known) corresponding
-decrypt function (in other words, the crypt() is a one-way hash
-function). As a result, this function isn't all that useful for
-cryptography. (For that, see your nearby CPAN mirror.)
-
-When verifying an existing encrypted string you should use the
-encrypted text as the salt (like C<crypt($plain, $crypted) eq
-$crypted>). This allows your code to work with the standard L<crypt|/crypt>
-and with more exotic implementations. In other words, do not assume
-anything about the returned string itself, or how many bytes in
-the encrypted string matter.
+Creates a digest string exactly like the crypt(3) function in the C
+library (assuming that you actually have a version there that has not
+been extirpated as a potential munition).
+
+crypt() is a one-way hash function. The PLAINTEXT and SALT is turned
+into a short string, called a digest, which is returned. The same
+PLAINTEXT and SALT will always return the same string, but there is no
+(known) way to get the original PLAINTEXT from the hash. Small
+changes in the PLAINTEXT or SALT will result in large changes in the
+digest.
+
+There is no decrypt function. This function isn't all that useful for
+cryptography (for that, look for F<Crypt> modules on your nearby CPAN
+mirror) and the name "crypt" is a bit of a misnomer. Instead it is
+primarily used to check if two pieces of text are the same without
+having to transmit or store the text itself. An example is checking
+if a correct password is given. The digest of the password is stored,
+not the password itself. The user types in a password which is
+crypt()'d with the same salt as the stored digest. If the two digests
+match the password is correct.
+
+When verifying an existing digest string you should use the digest as
+the salt (like C<crypt($plain, $digest) eq $digest>). The SALT used
+to create the digest is visible as part of the digest so this ensures
+crypt() will hash the new string with the same salt as the digest.
+This allows your code to work with the standard L<crypt|/crypt> and
+with more exotic implementations. In other words, do not assume
+anything about the returned string itself, or how many bytes in the
+digest matter.
Traditionally the result is a string of 13 bytes: two first bytes of
the salt, followed by 11 bytes from the set C<[./0-9A-Za-z]>, and only
-the first eight bytes of the encrypted string mattered, but
-alternative hashing schemes (like MD5), higher level security schemes
-(like C2), and implementations on non-UNIX platforms may produce
-different strings.
+the first eight bytes of the digest string mattered, but alternative
+hashing schemes (like MD5), higher level security schemes (like C2),
+and implementations on non-UNIX platforms may produce different
+strings.
When choosing a new salt create a random two character string whose
characters come from the set C<[./0-9A-Za-z]> (like C<join '', ('.',
Of course, typing in your own password to whoever asks you
for it is unwise.
-The L<crypt|/crypt> function is unsuitable for encrypting large quantities
+The L<crypt|/crypt> function is unsuitable for hashing large quantities
of data, not least of all because you can't get the information
-back. Look at the F<by-module/Crypt> and F<by-module/PGP> directories
-on your favorite CPAN mirror for a slew of potentially useful
-modules.
+back. Look at the L<Digest> module for more robust algorithms.
If using crypt() on a Unicode string (which I<potentially> has
characters with codepoints above 255), Perl tries to make sense
If LIST is empty and C<$@> contains an object reference that has a
C<PROPAGATE> method, that method will be called with additional file
and line number parameters. The return value replaces the value in
-C<$@>. ie. as if C<< $@ = eval { $@->PROPAGATE(__FILE__, __LINE__) }; >>
+C<$@>. i.e. as if C<< $@ = eval { $@->PROPAGATE(__FILE__, __LINE__) }; >>
were called.
If C<$@> is empty then the string C<"Died"> is used.
is sometimes preferable to matching particular string values of $@ using
regular expressions. Here's an example:
+ use Scalar::Util 'blessed';
+
eval { ... ; die Some::Module::Exception->new( FOO => "bar" ) };
if ($@) {
- if (ref($@) && UNIVERSAL::isa($@,"Some::Module::Exception")) {
+ if (blessed($@) && $@->isa("Some::Module::Exception")) {
# handle Some::Module::Exception
}
else {
=item eval BLOCK
+=item eval
+
In the first form, the return value of EXPR is parsed and executed as if it
were a little Perl program. The value of the expression (which is itself
determined within scalar context) is first parsed, and if there weren't any
=item exit EXPR
+=item exit
+
Evaluates EXPR and exits immediately with that value. Example:
$ans = <STDIN>;
=item gmtime EXPR
+=item gmtime
+
Converts a time as returned by the time function to an 8-element list
with the time localized for the standard Greenwich time zone.
Typically used as follows:
instead a Perl builtin. To get somewhat similar but locale dependent date
strings, see the example in L</localtime>.
+See L<perlport/gmtime> for portability concerns.
+
=item goto LABEL
=item goto EXPR
unlike oct(). To present something as hex, look into L</printf>,
L</sprintf>, or L</unpack>.
-=item import
+=item import LIST
There is no builtin C<import> function. It is just an ordinary
method (subroutine) defined (or inherited) by modules that wish to export
Implements the ioctl(2) function. You'll probably first have to say
- require "ioctl.ph"; # probably in /usr/local/lib/perl/ioctl.ph
+ require "sys/ioctl.ph"; # probably in $Config{archlib}/ioctl.ph
-to get the correct function definitions. If F<ioctl.ph> doesn't
+to get the correct function definitions. If F<sys/ioctl.ph> doesn't
exist or doesn't have the correct definitions you'll have to roll your
own, based on your C header files such as F<< <sys/ioctl.h> >>.
(There is a Perl script called B<h2ph> that comes with the Perl kit that
Note that the C<%a> and C<%b>, the short forms of the day of the week
and the month of the year, may not necessarily be three characters wide.
+See L<perlport/localtime> for portability concerns.
+
=item lock THING
This function places an advisory lock on a shared variable, or referenced
reading.
Since v5.8.0, perl has built using PerlIO by default. Unless you've
-changed this (ie Configure -Uuseperlio), you can open file handles to
+changed this (i.e. Configure -Uuseperlio), you can open file handles to
"in memory" files held in Perl scalars via:
open($fh, '>', \$variable) || ..
of $^F. See L<perlvar/$^F>.
Closing any piped filehandle causes the parent process to wait for the
-child to finish, and returns the status value in C<$?>.
+child to finish, and returns the status value in C<$?> and
+C<${^CHILD_ERROR_NATIVE}>.
The filename passed to 2-argument (or 1-argument) form of open() will
have leading and trailing whitespace deleted, and the normal
=item our TYPE EXPR : ATTRS
-An C<our> declares the listed variables to be valid globals within
-the enclosing block, file, or C<eval>. That is, it has the same
-scoping rules as a "my" declaration, but does not create a local
-variable. If more than one value is listed, the list must be placed
-in parentheses. The C<our> declaration has no semantic effect unless
-"use strict vars" is in effect, in which case it lets you use the
-declared global variable without qualifying it with a package name.
-(But only within the lexical scope of the C<our> declaration. In this
-it differs from "use vars", which is package scoped.)
+C<our> associates a simple name with a package variable in the current
+package for use within the current scope. When C<use strict 'vars'> is in
+effect, C<our> lets you use declared global variables without qualifying
+them with package names, within the lexical scope of the C<our> declaration.
+In this way C<our> differs from C<use vars>, which is package scoped.
+
+Unlike C<my>, which both allocates storage for a variable and associates a
+a simple name with that storage for use within the current scope, C<our>
+associates a simple name with a package variable in the current package,
+for use within the current scope. In other words, C<our> has the same
+scoping rules as C<my>, but does not necessarily create a
+variable.
+
+If more than one value is listed, the list must be placed
+in parentheses.
+
+ our $foo;
+ our($bar, $baz);
An C<our> declaration declares a global variable that will be visible
across its entire lexical scope, even across package boundaries. The
$bar = 20;
package Bar;
- print $bar; # prints 20
+ print $bar; # prints 20, as it refers to $Foo::bar
-Multiple C<our> declarations in the same lexical scope are allowed
-if they are in different packages. If they happened to be in the same
-package, Perl will emit warnings if you have asked for them.
+Multiple C<our> declarations with the same name in the same lexical
+scope are allowed if they are in different packages. If they happen
+to be in the same package, Perl will emit warnings if you have asked
+for them, just like multiple C<my> declarations. Unlike a second
+C<my> declaration, which will bind the name to a fresh variable, a
+second C<our> declaration in the same package, in the same scope, is
+merely redundant.
use warnings;
package Foo;
our $bar = 30; # declares $Bar::bar for rest of lexical scope
print $bar; # prints 30
- our $bar; # emits warning
+ our $bar; # emits warning but has no other effect
+ print $bar; # still prints 30
An C<our> declaration may also have a list of attributes associated
with it.
platforms are using IEEE, there may be subtle differences. Being able
to use C<E<gt>> or C<E<lt>> on floating point values can be very useful,
but also very dangerous if you don't know exactly what you're doing.
-It is definetely not a general way to portably store floating point
+It is definitely not a general way to portably store floating point
values.
When using C<E<gt>> or C<E<lt>> on an C<()>-group, this will affect
the print--interpose a C<+> or put parentheses around all the
arguments.
-Note that if you're storing FILEHANDLES in an array or other expression,
-you will have to use a block returning its value instead:
+Note that if you're storing FILEHANDLEs in an array, or if you're using
+any other expression more complex than a scalar variable to retrieve it,
+you will have to use a block returning the filehandle value instead:
print { $files[$i] } "stuff\n";
print { $OK ? STDOUT : STDERR } "stuff\n";
unless (ref($r)) {
print "r is not a reference at all.\n";
}
- if (UNIVERSAL::isa($r, "HASH")) { # for subclassing
- print "r is a reference to something that isa hash.\n";
- }
See also L<perlref>.
array by 1 and moving everything down. If there are no elements in the
array, returns the undefined value. If ARRAY is omitted, shifts the
C<@_> array within the lexical scope of subroutines and formats, and the
-C<@ARGV> array at file scopes or within the lexical scopes established by
-the C<eval ''>, C<BEGIN {}>, C<INIT {}>, C<CHECK {}>, and C<END {}>
-constructs.
+C<@ARGV> array outside of a subroutine and also within the lexical scopes
+established by the C<eval STRING>, C<BEGIN {}>, C<INIT {}>, C<CHECK {}>
+and C<END {}> constructs.
See also C<unshift>, C<push>, and C<pop>. C<shift> and C<unshift> do the
same thing to the left end of an array that C<pop> and C<push> do to the
produces the output 'h:i:t:h:e:r:e'.
-Using the empty pattern C<//> specifically matches the null string, and is
-not be confused with the use of C<//> to mean "the last successful pattern
-match". So, for C<split>, the following are equivalent:
+As a special case for C<split>, using the empty pattern C<//> specifically
+matches only the null string, and is not be confused with the regular use
+of C<//> to mean "the last successful pattern match". So, for C<split>,
+the following:
print join(':', split(//, 'hi there'));
- print join(':', split('', 'hi there'));
-
-and they produce the output 'h:i: :t:h:e:r:e'.
+produces the output 'h:i: :t:h:e:r:e'.
Empty leading (or trailing) fields are produced when there are positive
width matches at the beginning (or end) of the string; a zero-width match
printf "child exited with value %d\n", $? >> 8;
}
-or more portably by using the W*() calls of the POSIX extension;
-see L<perlport> for more information.
+Alternatively you might inspect the value of C<${^CHILD_ERROR_NATIVE}>
+with the W*() calls of the POSIX extension.
When the arguments get executed via the system shell, results
and return codes will be subject to its quirks and capabilities.
Behaves like the wait(2) system call on your system: it waits for a child
process to terminate and returns the pid of the deceased process, or
-C<-1> if there are no child processes. The status is returned in C<$?>.
+C<-1> if there are no child processes. The status is returned in C<$?>
+and C<{^CHILD_ERROR_NATIVE}>.
Note that a return value of C<-1> could mean that child processes are
being automatically reaped, as described in L<perlipc>.
Waits for a particular child process to terminate and returns the pid of
the deceased process, or C<-1> if there is no such child process. On some
systems, a value of 0 indicates that there are processes still running.
-The status is returned in C<$?>. If you say
+The status is returned in C<$?> and C<{^CHILD_ERROR_NATIVE}>. If you say
use POSIX ":sys_wait_h";
#...
projects / p5sagit/p5-mst-13.2.git / blobdiff