See L</@-> for a replacement.
+=item ${^MATCH}
+X<${^MATCH}>
+
+This is similar to C<$&> (C<$POSTMATCH>) except that it does not incur the
+performance penalty associated with that variable, and is only guaranteed
+to return a defined value when the pattern was compiled or executed with
+the C</p> modifier.
+
=item $PREMATCH
=item $`
See L</@-> for a replacement.
+=item ${^PREMATCH}
+X<${^PREMATCH}>
+
+This is similar to C<$`> ($PREMATCH) except that it does not incur the
+performance penalty associated with that variable, and is only guaranteed
+to return a defined value when the pattern was compiled or executed with
+the C</p> modifier.
+
=item $POSTMATCH
=item $'
See L</@-> for a replacement.
+=item ${^POSTMATCH}
+X<${^POSTMATCH}>
+
+This is similar to C<$'> (C<$POSTMATCH>) except that it does not incur the
+performance penalty associated with that variable, and is only guaranteed
+to return a defined value when the pattern was compiled or executed with
+the C</p> modifier.
+
=item $LAST_PAREN_MATCH
=item $+
(Mnemonic: be positive and forward looking.)
This variable is read-only and dynamically scoped to the current BLOCK.
+=item $LAST_SUBMATCH_RESULT
+
=item $^N
X<$^N>
how many subgroups were in the last successful match. See the
examples given for the C<@-> variable.
+=item %+
+X<%+>
+
+Similar to C<@+>, the C<%+> hash allows access to the named capture
+buffers, should they exist, in the last successful match in the
+currently active dynamic scope.
+
+For example, C<$+{foo}> is equivalent to C<$1> after the following match:
+
+ 'foo' =~ /(?<foo>foo)/;
+
+The keys of the C<%+> hash list only the names of buffers that have
+captured (and that are thus associated to defined values).
+
+The underlying behaviour of C<%+> is provided by the
+L<Tie::Hash::NamedCapture> module.
+
+B<Note:> C<%-> and C<%+> are tied views into a common internal hash
+associated with the last successful regular expression. Therefore mixing
+iterative access to them via C<each> may have unpredictable results.
+Likewise, if the last successful match changes, then the results may be
+surprising.
+
=item HANDLE->input_line_number(EXPR)
=item $INPUT_LINE_NUMBER
=item $.
X<$.> X<$NR> X<$INPUT_LINE_NUMBER> X<line number>
-Current line number for the last filehandle accessed.
+Current line number for the last filehandle accessed.
Each filehandle in Perl counts the number of lines that have been read
from it. (Depending on the value of C<$/>, Perl's idea of what
=back
+=item %-
+X<%->
+
+Similar to C<%+>, this variable allows access to the named capture buffers
+in the last successful match in the currently active dynamic scope. To
+each capture buffer name found in the regular expression, it associates a
+reference to an array containing the list of values captured by all
+buffers with that name (should there be several of them), in the order
+where they appear.
+
+Here's an example:
+
+ if ('1234' =~ /(?<A>1)(?<B>2)(?<A>3)(?<B>4)/) {
+ foreach my $bufname (sort keys %-) {
+ my $ary = $-{$bufname};
+ foreach my $idx (0..$#$ary) {
+ print "\$-{$bufname}[$idx] : ",
+ (defined($ary->[$idx]) ? "'$ary->[$idx]'" : "undef"),
+ "\n";
+ }
+ }
+ }
+
+would print out:
+
+ $-{A}[0] : '1'
+ $-{A}[1] : '3'
+ $-{B}[0] : '2'
+ $-{B}[1] : '4'
+
+The keys of the C<%-> hash correspond to all buffer names found in
+the regular expression.
+
+The behaviour of C<%-> is implemented via the
+L<Tie::Hash::NamedCapture> module.
+
+B<Note:> C<%-> and C<%+> are tied views into a common internal hash
+associated with the last successful regular expression. Therefore mixing
+iterative access to them via C<each> may have unpredictable results.
+Likewise, if the last successful match changes, then the results may be
+surprising.
+
=item HANDLE->format_name(EXPR)
=item $FORMAT_NAME
The I<object reference> to the Encode object that is used to convert
the source code to Unicode. Thanks to this variable your perl script
does not have to be written in UTF-8. Default is I<undef>. The direct
-manipulation of this variable is highly discouraged. See L<encoding>
-for more details.
+manipulation of this variable is highly discouraged.
=item $OS_ERROR
Also see L<Error Indicators>.
+=item %OS_ERROR
+
+=item %ERRNO
+
=item %!
X<%!>
However, a value assigned to C<$(> must be a single number used to
set the real gid. So the value given by C<$(> should I<not> be assigned
-back to C<$(> without being forced numeric, such as by adding zero.
+back to C<$(> without being forced numeric, such as by adding zero. Note
+that this is different to the effective gid (C<$)>) which does take a
+list.
You can change both the real gid and the effective gid at the same
time by using POSIX::setgid(). Changes to $( require a check to $!
The current value of the flag associated with the B<-c> switch.
Mainly of use with B<-MO=...> to allow code to alter its behavior
when being compiled, such as for example to AUTOLOAD at compile
-time rather than normal, deferred loading. See L<perlcc>. Setting
+time rather than normal, deferred loading. Setting
C<$^C = 1> is similar to calling C<B::minus_c>.
=item $DEBUGGING
as a string composed of characters with those ordinals. Thus in Perl v5.6.0
it equals C<chr(5) . chr(6) . chr(0)> and will return true for
C<$^V eq v5.6.0>. Note that the characters in this string value can
-potentially be in Unicode range.
+potentially be greater than 255.
This variable first appeared in perl 5.6.0; earlier versions of perl will
see an undefined value.
=item $SIG{expr}
X<%SIG>
-The hash %SIG contains signal handlers for signals. For example:
+The hash C<%SIG> contains signal handlers for signals. For example:
sub handler { # 1st argument is signal name
my($sig) = @_;
Certain internal hooks can be also set using the %SIG hash. The
routine indicated by C<$SIG{__WARN__}> is called when a warning message is
about to be printed. The warning message is passed as the first
-argument. The presence of a __WARN__ hook causes the ordinary printing
-of warnings to STDERR to be suppressed. You can use this to save warnings
+argument. The presence of a C<__WARN__> hook causes the ordinary printing
+of warnings to C<STDERR> to be suppressed. You can use this to save warnings
in a variable, or turn warnings into fatal errors, like this:
local $SIG{__WARN__} = sub { die $_[0] };
eval $proggie;
+As the C<'IGNORE'> hook is not supported by C<__WARN__>, you can
+disable warnings using the empty subroutine:
+
+ local $SIG{__WARN__} = sub {};
+
The routine indicated by C<$SIG{__DIE__}> is called when a fatal exception
is about to be thrown. The error message is passed as the first
-argument. When a __DIE__ hook routine returns, the exception
+argument. When a C<__DIE__> hook routine returns, the exception
processing continues as it would have in the absence of the hook,
-unless the hook routine itself exits via a C<goto>, a loop exit, or a die().
+unless the hook routine itself exits via a C<goto>, a loop exit, or a C<die()>.
The C<__DIE__> handler is explicitly disabled during the call, so that you
can die from a C<__DIE__> handler. Similarly for C<__WARN__>.
Due to an implementation glitch, the C<$SIG{__DIE__}> hook is called
even inside an eval(). Do not use this to rewrite a pending exception
-in C<$@>, or as a bizarre substitute for overriding CORE::GLOBAL::die().
+in C<$@>, or as a bizarre substitute for overriding C<CORE::GLOBAL::die()>.
This strange action at a distance may be fixed in a future release
so that C<$SIG{__DIE__}> is only called if your program is about
to exit, as was the original intent. Any other use is deprecated.
projects / p5sagit/p5-mst-13.2.git / blobdiff