787 lines
32 KiB
Plaintext
787 lines
32 KiB
Plaintext
=head1 NAME
|
|
|
|
perldata - Perl data types
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
=head2 Variable names
|
|
|
|
Perl has three built-in data types: scalars, arrays of scalars, and
|
|
associative arrays of scalars, known as "hashes". Normal arrays
|
|
are ordered lists of scalars indexed by number, starting with 0 and with
|
|
negative subscripts counting from the end. Hashes are unordered
|
|
collections of scalar values indexed by their associated string key.
|
|
|
|
Values are usually referred to by name, or through a named reference.
|
|
The first character of the name tells you to what sort of data
|
|
structure it refers. The rest of the name tells you the particular
|
|
value to which it refers. Usually this name is a single I<identifier>,
|
|
that is, a string beginning with a letter or underscore, and
|
|
containing letters, underscores, and digits. In some cases, it may
|
|
be a chain of identifiers, separated by C<::> (or by the slightly
|
|
archaic C<'>); all but the last are interpreted as names of packages,
|
|
to locate the namespace in which to look up the final identifier
|
|
(see L<perlmod/Packages> for details). It's possible to substitute
|
|
for a simple identifier, an expression that produces a reference
|
|
to the value at runtime. This is described in more detail below
|
|
and in L<perlref>.
|
|
|
|
Perl also has its own built-in variables whose names don't follow
|
|
these rules. They have strange names so they don't accidentally
|
|
collide with one of your normal variables. Strings that match
|
|
parenthesized parts of a regular expression are saved under names
|
|
containing only digits after the C<$> (see L<perlop> and L<perlre>).
|
|
In addition, several special variables that provide windows into
|
|
the inner working of Perl have names containing punctuation characters
|
|
and control characters. These are documented in L<perlvar>.
|
|
|
|
Scalar values are always named with '$', even when referring to a
|
|
scalar that is part of an array or a hash. The '$' symbol works
|
|
semantically like the English word "the" in that it indicates a
|
|
single value is expected.
|
|
|
|
$days # the simple scalar value "days"
|
|
$days[28] # the 29th element of array @days
|
|
$days{'Feb'} # the 'Feb' value from hash %days
|
|
$#days # the last index of array @days
|
|
|
|
Entire arrays (and slices of arrays and hashes) are denoted by '@',
|
|
which works much like the word "these" or "those" does in English,
|
|
in that it indicates multiple values are expected.
|
|
|
|
@days # ($days[0], $days[1],... $days[n])
|
|
@days[3,4,5] # same as ($days[3],$days[4],$days[5])
|
|
@days{'a','c'} # same as ($days{'a'},$days{'c'})
|
|
|
|
Entire hashes are denoted by '%':
|
|
|
|
%days # (key1, val1, key2, val2 ...)
|
|
|
|
In addition, subroutines are named with an initial '&', though this
|
|
is optional when unambiguous, just as the word "do" is often redundant
|
|
in English. Symbol table entries can be named with an initial '*',
|
|
but you don't really care about that yet (if ever :-).
|
|
|
|
Every variable type has its own namespace, as do several
|
|
non-variable identifiers. This means that you can, without fear
|
|
of conflict, use the same name for a scalar variable, an array, or
|
|
a hash--or, for that matter, for a filehandle, a directory handle, a
|
|
subroutine name, a format name, or a label. This means that $foo
|
|
and @foo are two different variables. It also means that C<$foo[1]>
|
|
is a part of @foo, not a part of $foo. This may seem a bit weird,
|
|
but that's okay, because it is weird.
|
|
|
|
Because variable references always start with '$', '@', or '%', the
|
|
"reserved" words aren't in fact reserved with respect to variable
|
|
names. They I<are> reserved with respect to labels and filehandles,
|
|
however, which don't have an initial special character. You can't
|
|
have a filehandle named "log", for instance. Hint: you could say
|
|
C<open(LOG,'logfile')> rather than C<open(log,'logfile')>. Using
|
|
uppercase filehandles also improves readability and protects you
|
|
from conflict with future reserved words. Case I<is> significant--"FOO",
|
|
"Foo", and "foo" are all different names. Names that start with a
|
|
letter or underscore may also contain digits and underscores.
|
|
|
|
It is possible to replace such an alphanumeric name with an expression
|
|
that returns a reference to the appropriate type. For a description
|
|
of this, see L<perlref>.
|
|
|
|
Names that start with a digit may contain only more digits. Names
|
|
that do not start with a letter, underscore, or digit are limited to
|
|
one character, e.g., C<$%> or C<$$>. (Most of these one character names
|
|
have a predefined significance to Perl. For instance, C<$$> is the
|
|
current process id.)
|
|
|
|
=head2 Context
|
|
|
|
The interpretation of operations and values in Perl sometimes depends
|
|
on the requirements of the context around the operation or value.
|
|
There are two major contexts: list and scalar. Certain operations
|
|
return list values in contexts wanting a list, and scalar values
|
|
otherwise. If this is true of an operation it will be mentioned in
|
|
the documentation for that operation. In other words, Perl overloads
|
|
certain operations based on whether the expected return value is
|
|
singular or plural. Some words in English work this way, like "fish"
|
|
and "sheep".
|
|
|
|
In a reciprocal fashion, an operation provides either a scalar or a
|
|
list context to each of its arguments. For example, if you say
|
|
|
|
int( <STDIN> )
|
|
|
|
the integer operation provides scalar context for the <>
|
|
operator, which responds by reading one line from STDIN and passing it
|
|
back to the integer operation, which will then find the integer value
|
|
of that line and return that. If, on the other hand, you say
|
|
|
|
sort( <STDIN> )
|
|
|
|
then the sort operation provides list context for <>, which
|
|
will proceed to read every line available up to the end of file, and
|
|
pass that list of lines back to the sort routine, which will then
|
|
sort those lines and return them as a list to whatever the context
|
|
of the sort was.
|
|
|
|
Assignment is a little bit special in that it uses its left argument
|
|
to determine the context for the right argument. Assignment to a
|
|
scalar evaluates the right-hand side in scalar context, while
|
|
assignment to an array or hash evaluates the righthand side in list
|
|
context. Assignment to a list (or slice, which is just a list
|
|
anyway) also evaluates the righthand side in list context.
|
|
|
|
When you use the C<use warnings> pragma or Perl's B<-w> command-line
|
|
option, you may see warnings
|
|
about useless uses of constants or functions in "void context".
|
|
Void context just means the value has been discarded, such as a
|
|
statement containing only C<"fred";> or C<getpwuid(0);>. It still
|
|
counts as scalar context for functions that care whether or not
|
|
they're being called in list context.
|
|
|
|
User-defined subroutines may choose to care whether they are being
|
|
called in a void, scalar, or list context. Most subroutines do not
|
|
need to bother, though. That's because both scalars and lists are
|
|
automatically interpolated into lists. See L<perlfunc/wantarray>
|
|
for how you would dynamically discern your function's calling
|
|
context.
|
|
|
|
=head2 Scalar values
|
|
|
|
All data in Perl is a scalar, an array of scalars, or a hash of
|
|
scalars. A scalar may contain one single value in any of three
|
|
different flavors: a number, a string, or a reference. In general,
|
|
conversion from one form to another is transparent. Although a
|
|
scalar may not directly hold multiple values, it may contain a
|
|
reference to an array or hash which in turn contains multiple values.
|
|
|
|
Scalars aren't necessarily one thing or another. There's no place
|
|
to declare a scalar variable to be of type "string", type "number",
|
|
type "reference", or anything else. Because of the automatic
|
|
conversion of scalars, operations that return scalars don't need
|
|
to care (and in fact, cannot care) whether their caller is looking
|
|
for a string, a number, or a reference. Perl is a contextually
|
|
polymorphic language whose scalars can be strings, numbers, or
|
|
references (which includes objects). Although strings and numbers
|
|
are considered pretty much the same thing for nearly all purposes,
|
|
references are strongly-typed, uncastable pointers with builtin
|
|
reference-counting and destructor invocation.
|
|
|
|
A scalar value is interpreted as TRUE in the Boolean sense if it is not
|
|
the null string or the number 0 (or its string equivalent, "0"). The
|
|
Boolean context is just a special kind of scalar context where no
|
|
conversion to a string or a number is ever performed.
|
|
|
|
There are actually two varieties of null strings (sometimes referred
|
|
to as "empty" strings), a defined one and an undefined one. The
|
|
defined version is just a string of length zero, such as C<"">.
|
|
The undefined version is the value that indicates that there is
|
|
no real value for something, such as when there was an error, or
|
|
at end of file, or when you refer to an uninitialized variable or
|
|
element of an array or hash. Although in early versions of Perl,
|
|
an undefined scalar could become defined when first used in a
|
|
place expecting a defined value, this no longer happens except for
|
|
rare cases of autovivification as explained in L<perlref>. You can
|
|
use the defined() operator to determine whether a scalar value is
|
|
defined (this has no meaning on arrays or hashes), and the undef()
|
|
operator to produce an undefined value.
|
|
|
|
To find out whether a given string is a valid non-zero number, it's
|
|
sometimes enough to test it against both numeric 0 and also lexical
|
|
"0" (although this will cause B<-w> noises). That's because strings
|
|
that aren't numbers count as 0, just as they do in B<awk>:
|
|
|
|
if ($str == 0 && $str ne "0") {
|
|
warn "That doesn't look like a number";
|
|
}
|
|
|
|
That method may be best because otherwise you won't treat IEEE
|
|
notations like C<NaN> or C<Infinity> properly. At other times, you
|
|
might prefer to determine whether string data can be used numerically
|
|
by calling the POSIX::strtod() function or by inspecting your string
|
|
with a regular expression (as documented in L<perlre>).
|
|
|
|
warn "has nondigits" if /\D/;
|
|
warn "not a natural number" unless /^\d+$/; # rejects -3
|
|
warn "not an integer" unless /^-?\d+$/; # rejects +3
|
|
warn "not an integer" unless /^[+-]?\d+$/;
|
|
warn "not a decimal number" unless /^-?\d+\.?\d*$/; # rejects .2
|
|
warn "not a decimal number" unless /^-?(?:\d+(?:\.\d*)?|\.\d+)$/;
|
|
warn "not a C float"
|
|
unless /^([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?$/;
|
|
|
|
The length of an array is a scalar value. You may find the length
|
|
of array @days by evaluating C<$#days>, as in B<csh>. Technically
|
|
speaking, this isn't the length of the array; it's the subscript
|
|
of the last element, since there is ordinarily a 0th element.
|
|
Assigning to C<$#days> actually changes the length of the array.
|
|
Shortening an array this way destroys intervening values. Lengthening
|
|
an array that was previously shortened does not recover values
|
|
that were in those elements. (It used to do so in Perl 4, but we
|
|
had to break this to make sure destructors were called when expected.)
|
|
|
|
You can also gain some miniscule measure of efficiency by pre-extending
|
|
an array that is going to get big. You can also extend an array
|
|
by assigning to an element that is off the end of the array. You
|
|
can truncate an array down to nothing by assigning the null list
|
|
() to it. The following are equivalent:
|
|
|
|
@whatever = ();
|
|
$#whatever = -1;
|
|
|
|
If you evaluate an array in scalar context, it returns the length
|
|
of the array. (Note that this is not true of lists, which return
|
|
the last value, like the C comma operator, nor of built-in functions,
|
|
which return whatever they feel like returning.) The following is
|
|
always true:
|
|
|
|
scalar(@whatever) == $#whatever - $[ + 1;
|
|
|
|
Version 5 of Perl changed the semantics of C<$[>: files that don't set
|
|
the value of C<$[> no longer need to worry about whether another
|
|
file changed its value. (In other words, use of C<$[> is deprecated.)
|
|
So in general you can assume that
|
|
|
|
scalar(@whatever) == $#whatever + 1;
|
|
|
|
Some programmers choose to use an explicit conversion so as to
|
|
leave nothing to doubt:
|
|
|
|
$element_count = scalar(@whatever);
|
|
|
|
If you evaluate a hash in scalar context, it returns false if the
|
|
hash is empty. If there are any key/value pairs, it returns true;
|
|
more precisely, the value returned is a string consisting of the
|
|
number of used buckets and the number of allocated buckets, separated
|
|
by a slash. This is pretty much useful only to find out whether
|
|
Perl's internal hashing algorithm is performing poorly on your data
|
|
set. For example, you stick 10,000 things in a hash, but evaluating
|
|
%HASH in scalar context reveals C<"1/16">, which means only one out
|
|
of sixteen buckets has been touched, and presumably contains all
|
|
10,000 of your items. This isn't supposed to happen.
|
|
|
|
You can preallocate space for a hash by assigning to the keys() function.
|
|
This rounds up the allocated bucked to the next power of two:
|
|
|
|
keys(%users) = 1000; # allocate 1024 buckets
|
|
|
|
=head2 Scalar value constructors
|
|
|
|
Numeric literals are specified in any of the following floating point or
|
|
integer formats:
|
|
|
|
12345
|
|
12345.67
|
|
.23E-10 # a very small number
|
|
4_294_967_296 # underline for legibility
|
|
0xff # hex
|
|
0377 # octal
|
|
0b011011 # binary
|
|
|
|
String literals are usually delimited by either single or double
|
|
quotes. They work much like quotes in the standard Unix shells:
|
|
double-quoted string literals are subject to backslash and variable
|
|
substitution; single-quoted strings are not (except for C<\'> and
|
|
C<\\>). The usual C-style backslash rules apply for making
|
|
characters such as newline, tab, etc., as well as some more exotic
|
|
forms. See L<perlop/"Quote and Quote-like Operators"> for a list.
|
|
|
|
Hexadecimal, octal, or binary, representations in string literals
|
|
(e.g. '0xff') are not automatically converted to their integer
|
|
representation. The hex() and oct() functions make these conversions
|
|
for you. See L<perlfunc/hex> and L<perlfunc/oct> for more details.
|
|
|
|
You can also embed newlines directly in your strings, i.e., they can end
|
|
on a different line than they begin. This is nice, but if you forget
|
|
your trailing quote, the error will not be reported until Perl finds
|
|
another line containing the quote character, which may be much further
|
|
on in the script. Variable substitution inside strings is limited to
|
|
scalar variables, arrays, and array or hash slices. (In other words,
|
|
names beginning with $ or @, followed by an optional bracketed
|
|
expression as a subscript.) The following code segment prints out "The
|
|
price is $Z<>100."
|
|
|
|
$Price = '$100'; # not interpreted
|
|
print "The price is $Price.\n"; # interpreted
|
|
|
|
As in some shells, you can enclose the variable name in braces to
|
|
disambiguate it from following alphanumerics. You must also do
|
|
this when interpolating a variable into a string to separate the
|
|
variable name from a following double-colon or an apostrophe, since
|
|
these would be otherwise treated as a package separator:
|
|
|
|
$who = "Larry";
|
|
print PASSWD "${who}::0:0:Superuser:/:/bin/perl\n";
|
|
print "We use ${who}speak when ${who}'s here.\n";
|
|
|
|
Without the braces, Perl would have looked for a $whospeak, a
|
|
C<$who::0>, and a C<$who's> variable. The last two would be the
|
|
$0 and the $s variables in the (presumably) non-existent package
|
|
C<who>.
|
|
|
|
In fact, an identifier within such curlies is forced to be a string,
|
|
as is any simple identifier within a hash subscript. Neither need
|
|
quoting. Our earlier example, C<$days{'Feb'}> can be written as
|
|
C<$days{Feb}> and the quotes will be assumed automatically. But
|
|
anything more complicated in the subscript will be interpreted as
|
|
an expression.
|
|
|
|
A literal of the form C<v1.20.300.4000> is parsed as a string composed
|
|
of characters with the specified ordinals. This provides an alternative,
|
|
more readable way to construct strings, rather than use the somewhat less
|
|
readable interpolation form C<"\x{1}\x{14}\x{12c}\x{fa0}">. This is useful
|
|
for representing Unicode strings, and for comparing version "numbers"
|
|
using the string comparison operators, C<cmp>, C<gt>, C<lt> etc.
|
|
If there are two or more dots in the literal, the leading C<v> may be
|
|
omitted.
|
|
|
|
print v9786; # prints UTF-8 encoded SMILEY, "\x{263a}"
|
|
print v102.111.111; # prints "foo"
|
|
print 102.111.111; # same
|
|
|
|
Such literals are accepted by both C<require> and C<use> for
|
|
doing a version check. The C<$^V> special variable also contains the
|
|
running Perl interpreter's version in this form. See L<perlvar/$^V>.
|
|
|
|
The special literals __FILE__, __LINE__, and __PACKAGE__
|
|
represent the current filename, line number, and package name at that
|
|
point in your program. They may be used only as separate tokens; they
|
|
will not be interpolated into strings. If there is no current package
|
|
(due to an empty C<package;> directive), __PACKAGE__ is the undefined
|
|
value.
|
|
|
|
The two control characters ^D and ^Z, and the tokens __END__ and __DATA__
|
|
may be used to indicate the logical end of the script before the actual
|
|
end of file. Any following text is ignored.
|
|
|
|
Text after __DATA__ but may be read via the filehandle C<PACKNAME::DATA>,
|
|
where C<PACKNAME> is the package that was current when the __DATA__
|
|
token was encountered. The filehandle is left open pointing to the
|
|
contents after __DATA__. It is the program's responsibility to
|
|
C<close DATA> when it is done reading from it. For compatibility with
|
|
older scripts written before __DATA__ was introduced, __END__ behaves
|
|
like __DATA__ in the toplevel script (but not in files loaded with
|
|
C<require> or C<do>) and leaves the remaining contents of the
|
|
file accessible via C<main::DATA>.
|
|
|
|
See L<SelfLoader> for more description of __DATA__, and
|
|
an example of its use. Note that you cannot read from the DATA
|
|
filehandle in a BEGIN block: the BEGIN block is executed as soon
|
|
as it is seen (during compilation), at which point the corresponding
|
|
__DATA__ (or __END__) token has not yet been seen.
|
|
|
|
A word that has no other interpretation in the grammar will
|
|
be treated as if it were a quoted string. These are known as
|
|
"barewords". As with filehandles and labels, a bareword that consists
|
|
entirely of lowercase letters risks conflict with future reserved
|
|
words, and if you use the C<use warnings> pragma or the B<-w> switch,
|
|
Perl will warn you about any
|
|
such words. Some people may wish to outlaw barewords entirely. If you
|
|
say
|
|
|
|
use strict 'subs';
|
|
|
|
then any bareword that would NOT be interpreted as a subroutine call
|
|
produces a compile-time error instead. The restriction lasts to the
|
|
end of the enclosing block. An inner block may countermand this
|
|
by saying C<no strict 'subs'>.
|
|
|
|
Arrays and slices are interpolated into double-quoted strings
|
|
by joining the elements with the delimiter specified in the C<$">
|
|
variable (C<$LIST_SEPARATOR> in English), space by default. The
|
|
following are equivalent:
|
|
|
|
$temp = join($", @ARGV);
|
|
system "echo $temp";
|
|
|
|
system "echo @ARGV";
|
|
|
|
Within search patterns (which also undergo double-quotish substitution)
|
|
there is an unfortunate ambiguity: Is C</$foo[bar]/> to be interpreted as
|
|
C</${foo}[bar]/> (where C<[bar]> is a character class for the regular
|
|
expression) or as C</${foo[bar]}/> (where C<[bar]> is the subscript to array
|
|
@foo)? If @foo doesn't otherwise exist, then it's obviously a
|
|
character class. If @foo exists, Perl takes a good guess about C<[bar]>,
|
|
and is almost always right. If it does guess wrong, or if you're just
|
|
plain paranoid, you can force the correct interpretation with curly
|
|
braces as above.
|
|
|
|
A line-oriented form of quoting is based on the shell "here-document"
|
|
syntax. Following a C<< << >> you specify a string to terminate
|
|
the quoted material, and all lines following the current line down to
|
|
the terminating string are the value of the item. The terminating
|
|
string may be either an identifier (a word), or some quoted text. If
|
|
quoted, the type of quotes you use determines the treatment of the
|
|
text, just as in regular quoting. An unquoted identifier works like
|
|
double quotes. There must be no space between the C<< << >> and
|
|
the identifier. (If you put a space it will be treated as a null
|
|
identifier, which is valid, and matches the first empty line.) The
|
|
terminating string must appear by itself (unquoted and with no
|
|
surrounding whitespace) on the terminating line.
|
|
|
|
print <<EOF;
|
|
The price is $Price.
|
|
EOF
|
|
|
|
print <<"EOF"; # same as above
|
|
The price is $Price.
|
|
EOF
|
|
|
|
print <<`EOC`; # execute commands
|
|
echo hi there
|
|
echo lo there
|
|
EOC
|
|
|
|
print <<"foo", <<"bar"; # you can stack them
|
|
I said foo.
|
|
foo
|
|
I said bar.
|
|
bar
|
|
|
|
myfunc(<<"THIS", 23, <<'THAT');
|
|
Here's a line
|
|
or two.
|
|
THIS
|
|
and here's another.
|
|
THAT
|
|
|
|
Just don't forget that you have to put a semicolon on the end
|
|
to finish the statement, as Perl doesn't know you're not going to
|
|
try to do this:
|
|
|
|
print <<ABC
|
|
179231
|
|
ABC
|
|
+ 20;
|
|
|
|
If you want your here-docs to be indented with the
|
|
rest of the code, you'll need to remove leading whitespace
|
|
from each line manually:
|
|
|
|
($quote = <<'FINIS') =~ s/^\s+//gm;
|
|
The Road goes ever on and on,
|
|
down from the door where it began.
|
|
FINIS
|
|
|
|
=head2 List value constructors
|
|
|
|
List values are denoted by separating individual values by commas
|
|
(and enclosing the list in parentheses where precedence requires it):
|
|
|
|
(LIST)
|
|
|
|
In a context not requiring a list value, the value of what appears
|
|
to be a list literal is simply the value of the final element, as
|
|
with the C comma operator. For example,
|
|
|
|
@foo = ('cc', '-E', $bar);
|
|
|
|
assigns the entire list value to array @foo, but
|
|
|
|
$foo = ('cc', '-E', $bar);
|
|
|
|
assigns the value of variable $bar to the scalar variable $foo.
|
|
Note that the value of an actual array in scalar context is the
|
|
length of the array; the following assigns the value 3 to $foo:
|
|
|
|
@foo = ('cc', '-E', $bar);
|
|
$foo = @foo; # $foo gets 3
|
|
|
|
You may have an optional comma before the closing parenthesis of a
|
|
list literal, so that you can say:
|
|
|
|
@foo = (
|
|
1,
|
|
2,
|
|
3,
|
|
);
|
|
|
|
To use a here-document to assign an array, one line per element,
|
|
you might use an approach like this:
|
|
|
|
@sauces = <<End_Lines =~ m/(\S.*\S)/g;
|
|
normal tomato
|
|
spicy tomato
|
|
green chile
|
|
pesto
|
|
white wine
|
|
End_Lines
|
|
|
|
LISTs do automatic interpolation of sublists. That is, when a LIST is
|
|
evaluated, each element of the list is evaluated in list context, and
|
|
the resulting list value is interpolated into LIST just as if each
|
|
individual element were a member of LIST. Thus arrays and hashes lose their
|
|
identity in a LIST--the list
|
|
|
|
(@foo,@bar,&SomeSub,%glarch)
|
|
|
|
contains all the elements of @foo followed by all the elements of @bar,
|
|
followed by all the elements returned by the subroutine named SomeSub
|
|
called in list context, followed by the key/value pairs of %glarch.
|
|
To make a list reference that does I<NOT> interpolate, see L<perlref>.
|
|
|
|
The null list is represented by (). Interpolating it in a list
|
|
has no effect. Thus ((),(),()) is equivalent to (). Similarly,
|
|
interpolating an array with no elements is the same as if no
|
|
array had been interpolated at that point.
|
|
|
|
A list value may also be subscripted like a normal array. You must
|
|
put the list in parentheses to avoid ambiguity. For example:
|
|
|
|
# Stat returns list value.
|
|
$time = (stat($file))[8];
|
|
|
|
# SYNTAX ERROR HERE.
|
|
$time = stat($file)[8]; # OOPS, FORGOT PARENTHESES
|
|
|
|
# Find a hex digit.
|
|
$hexdigit = ('a','b','c','d','e','f')[$digit-10];
|
|
|
|
# A "reverse comma operator".
|
|
return (pop(@foo),pop(@foo))[0];
|
|
|
|
Lists may be assigned to only when each element of the list
|
|
is itself legal to assign to:
|
|
|
|
($a, $b, $c) = (1, 2, 3);
|
|
|
|
($map{'red'}, $map{'blue'}, $map{'green'}) = (0x00f, 0x0f0, 0xf00);
|
|
|
|
An exception to this is that you may assign to C<undef> in a list.
|
|
This is useful for throwing away some of the return values of a
|
|
function:
|
|
|
|
($dev, $ino, undef, undef, $uid, $gid) = stat($file);
|
|
|
|
List assignment in scalar context returns the number of elements
|
|
produced by the expression on the right side of the assignment:
|
|
|
|
$x = (($foo,$bar) = (3,2,1)); # set $x to 3, not 2
|
|
$x = (($foo,$bar) = f()); # set $x to f()'s return count
|
|
|
|
This is handy when you want to do a list assignment in a Boolean
|
|
context, because most list functions return a null list when finished,
|
|
which when assigned produces a 0, which is interpreted as FALSE.
|
|
|
|
The final element may be an array or a hash:
|
|
|
|
($a, $b, @rest) = split;
|
|
my($a, $b, %rest) = @_;
|
|
|
|
You can actually put an array or hash anywhere in the list, but the first one
|
|
in the list will soak up all the values, and anything after it will become
|
|
undefined. This may be useful in a my() or local().
|
|
|
|
A hash can be initialized using a literal list holding pairs of
|
|
items to be interpreted as a key and a value:
|
|
|
|
# same as map assignment above
|
|
%map = ('red',0x00f,'blue',0x0f0,'green',0xf00);
|
|
|
|
While literal lists and named arrays are often interchangeable, that's
|
|
not the case for hashes. Just because you can subscript a list value like
|
|
a normal array does not mean that you can subscript a list value as a
|
|
hash. Likewise, hashes included as parts of other lists (including
|
|
parameters lists and return lists from functions) always flatten out into
|
|
key/value pairs. That's why it's good to use references sometimes.
|
|
|
|
It is often more readable to use the C<< => >> operator between key/value
|
|
pairs. The C<< => >> operator is mostly just a more visually distinctive
|
|
synonym for a comma, but it also arranges for its left-hand operand to be
|
|
interpreted as a string--if it's a bareword that would be a legal identifier.
|
|
This makes it nice for initializing hashes:
|
|
|
|
%map = (
|
|
red => 0x00f,
|
|
blue => 0x0f0,
|
|
green => 0xf00,
|
|
);
|
|
|
|
or for initializing hash references to be used as records:
|
|
|
|
$rec = {
|
|
witch => 'Mable the Merciless',
|
|
cat => 'Fluffy the Ferocious',
|
|
date => '10/31/1776',
|
|
};
|
|
|
|
or for using call-by-named-parameter to complicated functions:
|
|
|
|
$field = $query->radio_group(
|
|
name => 'group_name',
|
|
values => ['eenie','meenie','minie'],
|
|
default => 'meenie',
|
|
linebreak => 'true',
|
|
labels => \%labels
|
|
);
|
|
|
|
Note that just because a hash is initialized in that order doesn't
|
|
mean that it comes out in that order. See L<perlfunc/sort> for examples
|
|
of how to arrange for an output ordering.
|
|
|
|
=head2 Slices
|
|
|
|
A common way to access an array or a hash is one scalar element at a
|
|
time. You can also subscript a list to get a single element from it.
|
|
|
|
$whoami = $ENV{"USER"}; # one element from the hash
|
|
$parent = $ISA[0]; # one element from the array
|
|
$dir = (getpwnam("daemon"))[7]; # likewise, but with list
|
|
|
|
A slice accesses several elements of a list, an array, or a hash
|
|
simultaneously using a list of subscripts. It's more convenient
|
|
than writing out the individual elements as a list of separate
|
|
scalar values.
|
|
|
|
($him, $her) = @folks[0,-1]; # array slice
|
|
@them = @folks[0 .. 3]; # array slice
|
|
($who, $home) = @ENV{"USER", "HOME"}; # hash slice
|
|
($uid, $dir) = (getpwnam("daemon"))[2,7]; # list slice
|
|
|
|
Since you can assign to a list of variables, you can also assign to
|
|
an array or hash slice.
|
|
|
|
@days[3..5] = qw/Wed Thu Fri/;
|
|
@colors{'red','blue','green'}
|
|
= (0xff0000, 0x0000ff, 0x00ff00);
|
|
@folks[0, -1] = @folks[-1, 0];
|
|
|
|
The previous assignments are exactly equivalent to
|
|
|
|
($days[3], $days[4], $days[5]) = qw/Wed Thu Fri/;
|
|
($colors{'red'}, $colors{'blue'}, $colors{'green'})
|
|
= (0xff0000, 0x0000ff, 0x00ff00);
|
|
($folks[0], $folks[-1]) = ($folks[0], $folks[-1]);
|
|
|
|
Since changing a slice changes the original array or hash that it's
|
|
slicing, a C<foreach> construct will alter some--or even all--of the
|
|
values of the array or hash.
|
|
|
|
foreach (@array[ 4 .. 10 ]) { s/peter/paul/ }
|
|
|
|
foreach (@hash{keys %hash}) {
|
|
s/^\s+//; # trim leading whitespace
|
|
s/\s+$//; # trim trailing whitespace
|
|
s/(\w+)/\u\L$1/g; # "titlecase" words
|
|
}
|
|
|
|
A slice of an empty list is still an empty list. Thus:
|
|
|
|
@a = ()[1,0]; # @a has no elements
|
|
@b = (@a)[0,1]; # @b has no elements
|
|
@c = (0,1)[2,3]; # @c has no elements
|
|
|
|
But:
|
|
|
|
@a = (1)[1,0]; # @a has two elements
|
|
@b = (1,undef)[1,0,2]; # @b has three elements
|
|
|
|
This makes it easy to write loops that terminate when a null list
|
|
is returned:
|
|
|
|
while ( ($home, $user) = (getpwent)[7,0]) {
|
|
printf "%-8s %s\n", $user, $home;
|
|
}
|
|
|
|
As noted earlier in this document, the scalar sense of list assignment
|
|
is the number of elements on the right-hand side of the assignment.
|
|
The null list contains no elements, so when the password file is
|
|
exhausted, the result is 0, not 2.
|
|
|
|
If you're confused about why you use an '@' there on a hash slice
|
|
instead of a '%', think of it like this. The type of bracket (square
|
|
or curly) governs whether it's an array or a hash being looked at.
|
|
On the other hand, the leading symbol ('$' or '@') on the array or
|
|
hash indicates whether you are getting back a singular value (a
|
|
scalar) or a plural one (a list).
|
|
|
|
=head2 Typeglobs and Filehandles
|
|
|
|
Perl uses an internal type called a I<typeglob> to hold an entire
|
|
symbol table entry. The type prefix of a typeglob is a C<*>, because
|
|
it represents all types. This used to be the preferred way to
|
|
pass arrays and hashes by reference into a function, but now that
|
|
we have real references, this is seldom needed.
|
|
|
|
The main use of typeglobs in modern Perl is create symbol table aliases.
|
|
This assignment:
|
|
|
|
*this = *that;
|
|
|
|
makes $this an alias for $that, @this an alias for @that, %this an alias
|
|
for %that, &this an alias for &that, etc. Much safer is to use a reference.
|
|
This:
|
|
|
|
local *Here::blue = \$There::green;
|
|
|
|
temporarily makes $Here::blue an alias for $There::green, but doesn't
|
|
make @Here::blue an alias for @There::green, or %Here::blue an alias for
|
|
%There::green, etc. See L<perlmod/"Symbol Tables"> for more examples
|
|
of this. Strange though this may seem, this is the basis for the whole
|
|
module import/export system.
|
|
|
|
Another use for typeglobs is to pass filehandles into a function or
|
|
to create new filehandles. If you need to use a typeglob to save away
|
|
a filehandle, do it this way:
|
|
|
|
$fh = *STDOUT;
|
|
|
|
or perhaps as a real reference, like this:
|
|
|
|
$fh = \*STDOUT;
|
|
|
|
See L<perlsub> for examples of using these as indirect filehandles
|
|
in functions.
|
|
|
|
Typeglobs are also a way to create a local filehandle using the local()
|
|
operator. These last until their block is exited, but may be passed back.
|
|
For example:
|
|
|
|
sub newopen {
|
|
my $path = shift;
|
|
local *FH; # not my!
|
|
open (FH, $path) or return undef;
|
|
return *FH;
|
|
}
|
|
$fh = newopen('/etc/passwd');
|
|
|
|
Now that we have the C<*foo{THING}> notation, typeglobs aren't used as much
|
|
for filehandle manipulations, although they're still needed to pass brand
|
|
new file and directory handles into or out of functions. That's because
|
|
C<*HANDLE{IO}> only works if HANDLE has already been used as a handle.
|
|
In other words, C<*FH> must be used to create new symbol table entries;
|
|
C<*foo{THING}> cannot. When in doubt, use C<*FH>.
|
|
|
|
All functions that are capable of creating filehandles (open(),
|
|
opendir(), pipe(), socketpair(), sysopen(), socket(), and accept())
|
|
automatically create an anonymous filehandle if the handle passed to
|
|
them is an uninitialized scalar variable. This allows the constructs
|
|
such as C<open(my $fh, ...)> and C<open(local $fh,...)> to be used to
|
|
create filehandles that will conveniently be closed automatically when
|
|
the scope ends, provided there are no other references to them. This
|
|
largely eliminates the need for typeglobs when opening filehandles
|
|
that must be passed around, as in the following example:
|
|
|
|
sub myopen {
|
|
open my $fh, "@_"
|
|
or die "Can't open '@_': $!";
|
|
return $fh;
|
|
}
|
|
|
|
{
|
|
my $f = myopen("</etc/motd");
|
|
print <$f>;
|
|
# $f implicitly closed here
|
|
}
|
|
|
|
Another way to create anonymous filehandles is with the Symbol
|
|
module or with the IO::Handle module and its ilk. These modules
|
|
have the advantage of not hiding different types of the same name
|
|
during the local(). See the bottom of L<perlfunc/open()> for an
|
|
example.
|
|
|
|
=head1 SEE ALSO
|
|
|
|
See L<perlvar> for a description of Perl's built-in variables and
|
|
a discussion of legal variable names. See L<perlref>, L<perlsub>,
|
|
and L<perlmod/"Symbol Tables"> for more discussion on typeglobs and
|
|
the C<*foo{THING}> syntax.
|