Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

dynamic scoped variables in the debugger

0 views
Skip to first unread message

Nathan

unread,
Jul 26, 2008, 9:43:11 PM7/26/08
to
Hi,

I'm running Perl v5.8.8 compiled for linux. I was reading about the perl
debugger and ran the following script with the command "perl -d":

1 #!/ usr/bin/perl
2 $_ = "foo";
3 /foo/;
4
5 print "$&";
6 print "\n";

As expected it prints "foo" before the newline, and if I check the value
of $& in the debugger it does show "foo". However, if I omit line 5 of
the program then the debugger says $& is undefined when it reaches the
last print statement. I don't understand how this can be, is there some
subtlety to the way the debugger treats dynamically scoped variables?
Any insight anyone can offer would be great, thanks.

-Nathan

xho...@gmail.com

unread,
Jul 27, 2008, 8:47:08 PM7/27/08
to
Nathan <us...@serverrb.net> wrote:
> Hi,
>
> I'm running Perl v5.8.8 compiled for linux. I was reading about the perl
> debugger and ran the following script with the command "perl -d":
>
> 1 #!/ usr/bin/perl
> 2 $_ = "foo";
> 3 /foo/;
> 4
> 5 print "$&";
> 6 print "\n";
>
> As expected it prints "foo" before the newline, and if I check the value
> of $& in the debugger it does show "foo". However, if I omit line 5 of
> the program then the debugger says $& is undefined when it reaches the
> last print statement.

When the program is compiled, if the compiler sees $& being used,
then it tuns on the (expensive) code which causes $& to be set during
regex operations. If $& is not seen, then this code is not activated
and $& does not get populated.

> I don't understand how this can be, is there some
> subtlety to the way the debugger treats dynamically scoped variables?

This is not related to the debugger itself. The debugger is just giving
you a way arrange things so that you can inspect $& without perl knowing
you are going to do so. You can get the same behaviour using string eval:

perl -le '$_="foo"; /foo/; eval q{print "$&"}'

Also, $& is not just a dynamic variable (like $foo::bar), but a special
variable. It is the implementation details of this specialness that is
tripping you up.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Nathan

unread,
Jul 27, 2008, 10:32:55 PM7/27/08
to

Thanks Xho, I vaguely suspected something along those lines, but I guess
I underestimated how "special" the special variables are. Perl gives you
everything you need except consistency. :)

-Nathan

Greg Bacon

unread,
Jul 28, 2008, 12:36:58 PM7/28/08
to
In article <hbajk.8629$vn7....@flpi147.ffdc.sbc.com>,
Nathan <us...@serverrb.net> wrote:

: Thanks Xho, I vaguely suspected something along those lines, but I


: guess I underestimated how "special" the special variables are. Perl
: gives you everything you need except consistency. :)

As indicated in the perlvar documentation on $&, it's a hack
to improve performance.

Good style uses capture variables such as $&, $`, $', and $1
only after you know you have a match, e.g.,

#! /usr/bin/perl

$_ = "foo";

if (/foo/) {
print $&, "\n"
}

Greg
--
That's the difference between governments and individuals. Governments
don't care, individuals do.
-- Mark Twain

0 new messages