Syntax-K

Know-How für Ihr Projekt

Perl Documentation

NAME

perlvar - Perl predefined variables

DESCRIPTION

The Syntax of Variable Names

Variable names in Perl can have several formats. Usually, they must begin with a letter or underscore, in which case they can be arbitrarily long (up to an internal limit of 251 characters) and may contain letters, digits, underscores, or the special sequence :: or '. In this case, the part before the last :: or ' is taken to be a package qualifier; see perlmod. A Unicode letter that is not ASCII is not considered to be a letter unless pppppppppppppppppppppppppppppppppppppppppp is in effect, and somewhat more complicated rules apply; see "Identifier parsing" in perldata for details.

Perl variable names may also be a sequence of digits, a single punctuation character, or the two-character sequence: ^ (caret or CIRCUMFLEX ACCENT) followed by any one of the characters [][A-Z^_?\]. These names are all reserved for special uses by Perl; for example, the all-digits names are used to hold data captured by backreferences after a regular expression match.

Since Perl v5.6.0, Perl variable names may also be alphanumeric strings preceded by a caret. These must all be written in the form ${^Foo}; the braces are not optional. ${^Foo} denotes the scalar variable whose name is considered to be a control-F followed by two o's. These variables are reserved for future special uses by Perl, except for the ones that begin with ^_ (caret-underscore). No name that begins with ^_ will acquire a special meaning in any future version of Perl; such names may therefore be used safely in programs. $^_ itself, however, is reserved.

Perl identifiers that begin with digits or punctuation characters are exempt from the effects of the package declaration and are always forced to be in package main; they are also exempt from strict 'vars' errors. A few other names are also exempt in these ways:

ENV      STDIN
INC      STDOUT
ARGV     STDERR
ARGVOUT
SIG

In particular, the special ${^_XYZ} variables are always taken to be in package main, regardless of any package declarations presently in scope.

SPECIAL VARIABLES

The following names have special meaning to Perl. Most punctuation names have reasonable mnemonics, or analogs in the shells. Nevertheless, if you wish to use long variable names, you need only say:

use English;

at the top of your program. This aliases all the short names to the long names in the current package. Some even have medium names, generally borrowed from awk. For more info, please see English.

Before you continue, note the sort order for variables. In general, we first list the variables in case-insensitive, almost-lexigraphical order (ignoring the { or ^ preceding words, as in ${^UNICODE} or $^T), although $_ and @_ move up to the top of the pile. For variables with the same identifier, we list it in order of scalar, array, hash, and bareword.

General Variables

Variables related to regular expressions

Most of the special variables related to regular expressions are side effects. Perl sets these variables when it has a successful match, so you should check the match result before using them. For instance:

if( /P(A)TT(ER)N/ ) {
	print "I found $1 and $2\n";
	}

These variables are read-only and dynamically-scoped, unless we note otherwise.

The dynamic nature of the regular expression variables means that their value is limited to the block that they are in, as demonstrated by this bit of code:

my $outer = 'Wallace and Grommit';
my $inner = 'Mutt and Jeff';
my $pattern = qr/(\S+) and (\S+)/;
sub show_n { print "\$1 is $1; \$2 is $2\n" }
{
OUTER:
	show_n() if $outer =~ m/$pattern/;
	INNER: {
	    show_n() if $inner =~ m/$pattern/;
	    }
	show_n();
}

The output shows that while in the OUTER block, the values of $1 and $2 are from the match against $outer. Inside the INNER block, the values of $1 and $2 are from the match against $inner, but only until the end of the block (i.e. the dynamic scope). After the INNER block completes, the values of $1 and $2 return to the values for the match against $outer even though we have not made another match:

$1 is Wallace; $2 is Grommit
$1 is Mutt; $2 is Jeff
$1 is Wallace; $2 is Grommit

Performance issues

Traditionally in Perl, any use of any of the three variables $`, $& or $' (or their use English equivalents) anywhere in the code, caused all subsequent successful pattern matches to make a copy of the matched string, in case the code might subsequently access one of those variables. This imposed a considerable performance penalty across the whole program, so generally the use of these variables has been discouraged.

In Perl 5.6.0 the @- and @+ dynamic arrays were introduced that supply the indices of successful matches. So you could for example do this:

$str =~ /pattern/;
print $`, $&, $'; # bad: perfomance hit
print             # good: no perfomance hit
	substr($str, 0,     $-[0]),
	substr($str, $-[0], $+[0]-$-[0]),
	substr($str, $+[0]);

In Perl 5.10.0 the /p match operator flag and the ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} variables were introduced, that allowed you to suffer the penalties only on patterns marked with /p.

In Perl 5.18.0 onwards, perl started noting the presence of each of the three variables separately, and only copied that part of the string required; so in

$`; $&; "abcdefgh" =~ /d/

perl would only copy the "abcd" part of the string. That could make a big difference in something like

$str = 'x' x 1_000_000;
$&; # whoops
$str =~ /x/g # one char copied a million times, not a million chars

In Perl 5.20.0 a new copy-on-write system was enabled by default, which finally fixes all performance issues with these three variables, and makes them safe to use anywhere.

The Devel::NYTProf and Devel::FindAmpersand modules can help you find uses of these problematic match variables in your code.

Variables related to filehandles

Variables that depend on the currently selected filehandle may be set by calling an appropriate object method on the IO::Handle object, although this is less efficient than using the regular built-in variables. (Summary lines below for this contain the word HANDLE.) First you must say

use IO::Handle;

after which you may use either

method HANDLE EXPR

or more safely,

HANDLE->method(EXPR)

Each method returns the old value of the IO::Handle attribute. The methods each take an optional EXPR, which, if supplied, specifies the new value for the IO::Handle attribute in question. If not supplied, most methods do nothing to the current value--except for autoflush(), which will assume a 1 for you, just to be different.

Because loading in the IO::Handle class is an expensive operation, you should learn how to use the regular built-in variables.

A few of these variables are considered "read-only". This means that if you try to assign to this variable, either directly or indirectly through a reference, you'll raise a run-time exception.

You should be very careful when modifying the default values of most special variables described in this document. In most cases you want to localize these variables before changing them, since if you don't, the change may affect other modules which rely on the default values of the special variables that you have changed. This is one of the correct ways to read the whole file at once:

open my $fh, "<", "foo" or die $!;
local $/; # enable localized slurp mode
my $content = <$fh>;
close $fh;

But the following code is quite bad:

open my $fh, "<", "foo" or die $!;
undef $/; # enable slurp mode
my $content = <$fh>;
close $fh;

since some other module, may want to read data from some file in the default "line mode", so if the code we have just presented has been executed, the global value of $/ is now changed for any other code running inside the same Perl interpreter.

Usually when a variable is localized you want to make sure that this change affects the shortest scope possible. So unless you are already inside some short {} block, you should create one yourself. For example:

my $content = '';
open my $fh, "<", "foo" or die $!;
{
	local $/;
	$content = <$fh>;
}
close $fh;

Here is an example of how your own code can go broken:

for ( 1..3 ){
	$\ = "\r\n";
	nasty_break();
	print "$_";
}
sub nasty_break {
	$\ = "\f";
	# do something with $_
}

You probably expect this code to print the equivalent of

"1\r\n2\r\n3\r\n"

but instead you get:

"1\f2\f3\f"

Why? Because nasty_break() modifies $\ without localizing it first. The value you set in nasty_break() is still there when you return. The fix is to add local() so the value doesn't leak out of nasty_break():

local $\ = "\f";

It's easy to notice the problem in such a short example, but in more complicated code you are looking for trouble if you don't localize changes to the special variables.

Variables related to formats

The special variables for formats are a subset of those for filehandles. See perlform for more information about Perl's formats.

Error Variables

The variables $@, $!, $^E, and $? contain information about different types of error conditions that may appear during execution of a Perl program. The variables are shown ordered by the "distance" between the subsystem which reported the error and the Perl process. They correspond to errors detected by the Perl interpreter, C library, operating system, or an external program, respectively.

To illustrate the differences between these variables, consider the following Perl expression, which uses a single-quoted string. After execution of this statement, perl may have set all four special error variables:

eval q{
	open my $pipe, "/cdrom/install |" or die $!;
	my @res = <$pipe>;
	close $pipe or die "bad pipe: $?, $!";
};

When perl executes the eval() expression, it translates the open(), <PIPE>, and close calls in the C run-time library and thence to the operating system kernel. perl sets $! to the C library's errno if one of these calls fails.

$@ is set if the string to be eval-ed did not compile (this may happen if open or close were imported with bad prototypes), or if Perl code executed during evaluation die()d. In these cases the value of $@ is the compile error, or the argument to die (which will interpolate $! and $?). (See also Fatal, though.)

Under a few operating systems, $^E may contain a more verbose error indicator, such as in this case, "CDROM tray not closed." Systems that do not support extended error messages leave $^E the same as $!.

Finally, $? may be set to a non-0 value if the external program /cdrom/install fails. The upper eight bits reflect specific error conditions encountered by the program (the program's exit() value). The lower eight bits reflect mode of failure, like signal death and core dump information. See wait(2) for details. In contrast to $! and $^E, which are set only if an error condition is detected, the variable $? is set on each wait or pipe close, overwriting the old value. This is more like $@, which on every eval() is always set on failure and cleared on success.

For more details, see the individual descriptions at $@, $!, $^E, and $?.

Variables related to the interpreter state

These variables provide information about the current interpreter state.

Deprecated and removed variables

Deprecating a variable announces the intent of the perl maintainers to eventually remove the variable from the language. It may still be available despite its status. Using a deprecated variable triggers a warning.

Once a variable is removed, its use triggers an error telling you the variable is unsupported.

See perldiag for details about error messages.