in reply to Re: Use of uninitialized value $1
in thread Use of uninitialized value $1

$1, $2.. etc are weird variables. ... they disappear when ... a new regexp is encountered. [Emphasis Added]

Even more weird! These variables keep their value until a new regex is successfully matched or dynamic scope is exited.

c:\@Work\Perl\monks>perl -wMstrict -MData::Dump -le "my $str = 'foo--bar'; dd $1, $2; ;; $str =~ m{ (foo) .* (bar) }xms; print qq{A: \$1 '$1' \$2 '$2'}; ;; $str =~ m{ (x) .* (y) }xms; print qq{B: \$1 '$1' \$2 '$2'}; " (undef, undef) A: $1 'foo' $2 'bar' B: $1 'foo' $2 'bar'


Give a man a fish:  <%-{-{-{-<

Replies are listed 'Best First'.
Re^3: Use of uninitialized value $1
by Marshall (Canon) on Aug 25, 2016 at 19:15 UTC
    "These variables keep their value until a new regex is successfully matched or dynamic scope is exited."

    I'm not sure that is true. I remember a node that fairly recently talked about this, but I couldn't find it, only What's happening to my $1?.

    What I remember is that a failed match could in some circumstances modify $1. So $1 is only reliable if the match succeeds (can't rely upon it being what it was after the previous regex after a failed match). I also remember that this behavior is Perl version specific.

    I haven't run across this in my code as I do whatever I'm going to do with $1 right after the regex and have never written code that decides whether $1 changed or not. I only use $1 if the match succeeded.

    Yes, this is a nit, but Perl Monks is good about resolving these nits and details.

      Yes, this is a nit ...

      Regular expressions, love them though I do, consist in a vast collection of nits IMHO.

      I'm not sure that [these variables keep their value] is true. I remember a node that fairly recently talked about this, but I couldn't find it ... What I remember is that a failed match could in some circumstances modify $1.

      Now that you mention it, I seem to remember something along those lines myself. Unfortunately, my Super Search-fu is no better than yours, and I could come up with no pertinent node. Have to keep searching, searching... (Maybe it had to do with the match portion of  s/// having the same effects on regex variables as  m// does?)

        perlre says:

        NOTE: Failed matches in Perl do not reset the match variables, which makes it easier to write code that tests for a series of more specific cases and remembers the best match.
        However, we both remember something different about that.
        I hope some other Monk can point us in the right direction.

        Update: After some reflection, my memory recalls some situation where there were several capture groups, $1,$2,$3. Overall, the match failed, but the first part ($1) did match and change $1 although the rest of the expression $2,$3 didn't match and didn't change. This behavior was version specific. So, this is a cautionary note that despite what the doc says, there may be some "bite you" case out there that my super-search foo is not able to find.