perlfunc.pod

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

X<crypt> X<digest> X<hash> X<salt> X<plaintext> X<password>
X<decrypt> X<cryptography> X<passwd> X<encrypt>

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

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 that 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.  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 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 '', ('.',
'/', 0..9, 'A'..'Z', 'a'..'z')[rand 64, rand 64]>).  This set of
characters is just a recommendation; the characters allowed in
the salt depend solely on your system's crypt library, and Perl can't
restrict what salts C<crypt()> accepts.

Here's an example that makes sure that whoever runs this program knows
their password:

    $pwd = (getpwuid($<))[1];

    system "stty -echo";
    print "Password: ";
    chomp($word = <STDIN>);
    print "\n";
    system "stty echo";

    if (crypt($word, $pwd) ne $pwd) {
	die "Sorry...\n";
    } else {
	print "ok\n";
    }

Of course, typing in your own password to whoever asks you
for it is unwise.

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 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
of the situation by trying to downgrade (a copy of the string)
the string back to an eight-bit byte string before calling crypt()
(on that copy).  If that works, good.  If not, crypt() dies with
C<Wide character in crypt>.

=item dbmclose HASH
X<dbmclose>

[This function has been largely superseded by the C<untie> function.]

Breaks the binding between a DBM file and a hash.

=item dbmopen HASH,DBNAME,MASK
X<dbmopen> X<dbm> X<ndbm> X<sdbm> X<gdbm>

[This function has been largely superseded by the C<tie> function.]

This binds a dbm(3), ndbm(3), sdbm(3), gdbm(3), or Berkeley DB file to a
hash.  HASH is the name of the hash.  (Unlike normal C<open>, the first
argument is I<not> a filehandle, even though it looks like one).  DBNAME
is the name of the database (without the F<.dir> or F<.pag> extension if
any).  If the database does not exist, it is created with protection
specified by MASK (as modified by the C<umask>).  If your system supports
only the older DBM functions, you may perform only one C<dbmopen> in your
program.  In older versions of Perl, if your system had neither DBM nor
ndbm, calling C<dbmopen> produced a fatal error; it now falls back to
sdbm(3).

If you don't have write access to the DBM file, you can only read hash
variables, not set them.  If you want to test whether you can write,
either use file tests or try setting a dummy hash entry inside an C<eval>,
which will trap the error.

Note that functions such as C<keys> and C<values> may return huge lists
when used on large DBM files.  You may prefer to use the C<each>
function to iterate over large DBM files.  Example:

    # print out history file offsets
    dbmopen(%HIST,'/usr/lib/news/history',0666);
    while (($key,$val) = each %HIST) {
	print $key, ' = ', unpack('L',$val), "\n";
    }
    dbmclose(%HIST);

See also L<AnyDBM_File> for a more general description of the pros and
cons of the various dbm approaches, as well as L<DB_File> for a particularly
rich implementation.

You can control which DBM library you use by loading that library
before you call dbmopen():

    use DB_File;
    dbmopen(%NS_Hist, "$ENV{HOME}/.netscape/history.db")
	or die "Can't open netscape history file: $!";

=item defined EXPR
X<defined> X<undef> X<undefined>

=item defined

Returns a Boolean value telling whether EXPR has a value other than
the undefined value C<undef>.  If EXPR is not present, C<$_> will be
checked.

Many operations return C<undef> to indicate failure, end of file,
system error, uninitialized variable, and other exceptional
conditions.  This function allows you to distinguish C<undef> from
other values.  (A simple Boolean test will not distinguish among
C<undef>, zero, the empty string, and C<"0">, which are all equally
false.)  Note that since C<undef> is a valid scalar, its presence
doesn't I<necessarily> indicate an exceptional condition: C<pop>
returns C<undef> when its argument is an empty array, I<or> when the
element to return happens to be C<undef>.

You may also use C<defined(&func)> to check whether subroutine C<&func>
has ever been defined.  The return value is unaffected by any forward
declarations of C<&func>.  Note that a subroutine which is not defined
may still be callable: its package may have an C<AUTOLOAD> method that
makes it spring into existence the first time that it is called -- see
L<perlsub>.

Use of C<defined> on aggregates (hashes and arrays) is deprecated.  It
used to report whether memory for that aggregate has ever been
allocated.  This behavior may disappear in future versions of Perl.
You should instead use a simple test for size:

    if (@an_array) { print "has array elements\n" }
    if (%a_hash)   { print "has hash members\n"   }

When used on a hash element, it tells you whether the value is defined,
not whether the key exists in the hash.  Use L</exists> for the latter
purpose.

Examples:

    print if defined $switch{'D'};
    print "$val\n" while defined($val = pop(@ary));
    die "Can't readlink $sym: $!"
	unless defined($value = readlink $sym);
    sub foo { defined &$bar ? &$bar(@_) : die "No bar"; }
    $debugging = 0 unless defined $debugging;

Note:  Many folks tend to overuse C<defined>, and then are surprised to
discover that the number C<0> and C<""> (the zero-length string) are, in fact,
defined values.  For example, if you say

    "ab" =~ /a(.*)b/;

The pattern match succeeds, and C<$1> is defined, despite the fact that it
matched "nothing".  It didn't really fail to match anything.  Rather, it
matched something that happened to be zero characters long.  This is all
very above-board and honest.  When a function returns an undefined value,
it's an admission that it couldn't give you an honest answer.  So you
should use C<defined> only when you're questioning the integrity of what
you're trying to do.  At other times, a simple comparison to C<0> or C<""> is
what you want.

See also L</undef>, L</exists>, L</ref>.

=item delete EXPR
X<delete>

Given an expression that specifies a hash element, array element, hash slice,
or array slice, deletes the specified element(s) from the hash or array.
In the case of an array, if the array elements happen to be at the end,
the size of the array will shrink to the highest element that tests
true for exists() (or 0 if no such element exists).

Returns a list with the same number of elements as the number of elements
for which deletion was attempted.  Each element of that list consists of
either the value of the element deleted, or the undefined value.  In scalar
context, this means that you get the value of the last element deleted (or
the undefined value if that element did not exist).

    %hash = (foo => 11, bar => 22, baz => 33);
    $scalar = delete $hash{foo};             # $scalar is 11
    $scalar = delete @hash{qw(foo bar)};     # $scalar is 22
    @array  = delete @hash{qw(foo bar baz)}; # @array  is (undef,undef,33)

Deleting from C<%ENV> modifies the environment.  Deleting from
a hash tied to a DBM file deletes the entry from the DBM file.  Deleting
from a C<tie>d hash or array may not necessarily return anything.

Deleting an array element effectively returns that position of the array
to its initial, uninitialized state.  Subsequently testing for the same
element with exists() will return false.  Also, deleting array elements
in the middle of an array will not shift the index of the elements
after them down.  Use splice() for that.  See L</exists>.

The following (inefficiently) deletes all the values of %HASH and @ARRAY:

    foreach $key (keys %HASH) {
	delete $HASH{$key};
    }

    foreach $index (0 .. $#ARRAY) {
	delete $ARRAY[$index];
    }

And so do these:

    delete @HASH{keys %HASH};

    delete @ARRAY[0 .. $#ARRAY];

But both of these are slower than just assigning the empty list
or undefining %HASH or @ARRAY:

    %HASH = ();		# completely empty %HASH
    undef %HASH;	# forget %HASH ever existed

    @ARRAY = ();	# completely empty @ARRAY
    undef @ARRAY;	# forget @ARRAY ever existed

Note that the EXPR can be arbitrarily complicated as long as the final
operation is a hash element, array element,  hash slice, or array slice
lookup:

    delete $ref->[$x][$y]{$key};
    delete @{$ref->[$x][$y]}{$key1, $key2, @morekeys};

    delete $ref->[$x][$y][$index];
    delete @{$ref->[$x][$y]}[$index1, $index2, @moreindices];

=item die LIST
X<die> X<throw> X<exception> X<raise> X<$@> X<abort>

Outside an C<eval>, prints the value of LIST to C<STDERR> and
exits with the current value of C<$!> (errno).  If C<$!> is C<0>,
exits with the value of C<<< ($? >> 8) >>> (backtick `command`
status).  If C<<< ($? >> 8) >>> is C<0>, exits with C<255>.  Inside
an C<eval(),> the error message is stuffed into C<$@> and the
C<eval> is terminated with the undefined value.  This makes
C<die> the way to raise an exception.

Equivalent examples:

    die "Can't cd to spool: $!\n" unless chdir '/usr/spool/news';
    chdir '/usr/spool/news' or die "Can't cd to spool: $!\n"

If the last element of LIST does not end in a newline, the current
script line number and input line number (if any) are also printed,
and a newline is supplied.  Note that the "input line number" (also
known as "chunk") is subject to whatever notion of "line" happens to
be currently in effect, and is also available as the special variable
C<$.>.  See L<perlvar/"$/"> and L<perlvar/"$.">.

Hint: sometimes appending C<", stopped"> to your message will cause it
to make better sense when the string C<"at foo line 123"> is appended.
Suppose you are running script "canasta".

    die "/etc/games is no good";
    die "/etc/games is no good, stopped";

produce, respectively

    /etc/games is no good at canasta line 123.
    /etc/games is no good, stopped at canasta line 123.

See also exit(), warn(), and the Carp module.

If LIST is empty and C<$@> already contains a value (typically from a
previous eval) that value is reused after appending C<"\t...propagated">.
This is useful for propagating exceptions:

    eval { ... };
    die unless $@ =~ /Expected exception/;

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<$@>.  i.e. as if C<< $@ = eval { $@->PROPAGATE(__FILE__, __LINE__) }; >>
were called.

If C<$@> is empty then the string C<"Died"> is used.

die() can also be called with a reference argument.  If this happens to be
trapped within an eval(), $@ contains the reference.  This behavior permits
a more elaborate exception handling implementation using objects that
maintain arbitrary state about the nature of the exception.  Such a scheme
is sometimes preferable to matching particular string values of $@ using
regular expressions.  Because $@ is a global variable, and eval() may be
used within object implementations, care must be taken that analyzing the
error object doesn't replace the reference in the global variable.  The
easiest solution is to make a local copy of the reference before doing
other manipulations.  Here's an example:

    use Scalar::Util 'blessed';

    eval { ... ; die Some::Module::Exception->new( FOO => "bar" ) };
    if (my $ev_err = $@) {
        if (blessed($ev_err) && $ev_err->isa("Some::Module::Exception")) {
            # handle Some::Module::Exception