johnnywang has asked for the wisdom of the Perl Monks concerning the following question:

While I was trying to learn something about perl internals and playing with Devel::Peek, I noticed the following behavior that I don't understand. The following simple script:
# devel.pl use Devel::Peek; my $a = undef; Dump $a; my $b = \$a; Dump $a; # note the reference count for $a
produces the correct reference count for $a when running "perl -d devel.pl", the output is as follows:
c:>perl -d devel.pl Loading DB routines from perl5db.pl version 1.23 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(devel.pl:3): my $a = undef; DB<1> n main::(devel.pl:4): Dump $a; DB<1> n SV = NULL(0x0) at 0x1829ce0 REFCNT = 1 FLAGS = (PADBUSY,PADMY) main::(devel.pl:5): my $b = \$a; DB<1> n main::(devel.pl:6): Dump $a; DB<1> n SV = NULL(0x0) at 0x1829ce0 REFCNT = 2 ###<----- correct count FLAGS = (PADBUSY,PADMY)
But if I do an interactive session using "perl -de 1", it produces the wrong count for $a:
c:>perl -de 1 Loading DB routines from perl5db.pl version 1.23 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 1 DB<1> use Devel::Peek; DB<2> my $a = undef; DB<3> Dump $a; SV = NULL(0x0) at 0x1aeccfc REFCNT = 1 FLAGS = () DB<4> my $b = \$a; DB<5> Dump $a; SV = NULL(0x0) at 0x1aeccfc REFCNT = 1 ###<----- wrong reference count FLAGS = ()
However, if I do not use "my" in the above interactive session, all is well:
c:>perl -de 1 Loading DB routines from perl5db.pl version 1.23 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 1 DB<1> use Devel::Peek; DB<2> $a = undef; DB<3> Dump $a; SV = NULL(0x0) at 0x1aecc18 REFCNT = 1 FLAGS = () DB<4> $b = \$a; DB<5> Dump $a; SV = NULL(0x0) at 0x1aecc18 REFCNT = 2 ###<--------correct here FLAGS = ()
What's going on here?

Replies are listed 'Best First'.
Re: Strange behavior of "my" in "perl -d" and "perl -de"
by tlm (Prior) on Apr 15, 2005 at 22:37 UTC

    The thing is that within "perl -d", each line you type interactively is effectively in it's own block. Try the following:

    DB<1> my $x = 1 DB<2> p $x DB<3> $x = 1 DB<4> p $x 1
    Notice how the first initialization of $x did not persist, since that $x was a lexical, and hence confined to the scope of that line. The second initialization of $x did persist, however, because this $x is in fact $main::x:
    DB<5> p $main::x 1

    Update: One other consequence of the fact that every line you type lives in its own block is that global variables that are implicitly localized to the enclosing scope (i.e. regexp-matching variables like $&, $', $`, $1, $2, $3...) will not survive from one line you type to the next. For example

    DB<1> 'a' =~ /(.)/ DB<2> print $1 DB<3> 'a' =~ /(.)/ && print $1 a DB<4>
    Therefore, if you want to be able to use one of these variables over several lines, assign it to a package global:
    DB<5> 'a' =~ /(.)/ && $g = $1 DB<6> print $g a DB<7>

    Update: Added some emphasis.

    the lowliest monk

Re: Strange behavior of "my" in "perl -d" and "perl -de"
by Fletch (Bishop) on Apr 15, 2005 at 23:40 UTC

    Yup, and perldoc perldebug mentions this fact.

    Note that the said "eval" is bound by an implicit scope. As a r +esult any newly introduced lexical variable or any modified capture b +uffer content is lost after the eval. The debugger is a nice environm +ent to learn Perl, but if you interactively experiment using material +which should be in the same scope, stuff it in one line.
      I still don't understand, why then is the first experiment using "perl -d devel.pl" producing the correct reference count?

        This warning applies only to code you type in interactively. Read all of the surrounding section in perldoc perldebug and it should make more sense.