in reply to Re^4: Error: Use of uninitialized value $item in concatenation (.) or string at...
in thread Error: Use of uninitialized value $item in concatenation (.) or string at...

By the way, don't you mean if it _doesn't_ have any commas in it?

If the string had no commas, there would be no successful match in the regex 'search' phase of the substitution, and  $1 and  $2 and any other capture variables would not be undef-ed. See the substitution statement
    $x =~ s/x//g;
that is the second to the last statement in ig's example code in Re^5: Error: Use of uninitialized value $item in concatenation (.) or string at...: the successful match against  $x causes all capture variables to be set to the values of their corresponding capture groups, and since there are no capture groups, these values are all undef.

Replies are listed 'Best First'.
Re^6: Error: Use of uninitialized value $item in concatenation (.) or string at...
by jonc (Beadle) on Jun 11, 2011 at 19:05 UTC

    You guys are great. I'll try testing my own ideas before coming here next time....

    Basically, $1 and $2 take the value of inside the parentheses() of the last successful match (ie. the match is true). If there are no parentheses, they take the value of undef. If there is no match they don't get overwritten ...

    Edit credit: AnomalousMonk and ig (not sure if I took the right steps here, can I just delete mine and rely on AnomalousMonk 's?).

    Thanks a lot!

      The capture variables ($1 $2 etc.) are set to the contents of their corresponding capture groups if there is a match; if there is no corresponding capture group, the capture variable is set to undef. If there is no match, the capture variable is uncanged.

      Basically, $1 and $2 only become 'undef'-ed when there is a un*successful* match.

      I'm not sure what you mean by "un*successful*", but it is likely to be (mis-)understood to mean something that is incorrect.

      AnomalousMonk has told you correctly. To emphasize where I think you may have gone wrong (or at least easily misunderstood as wrong) I might rewrite what you wrote as:

      Basically, $1 and $2 only become 'undef'-ed when there is a successful match and the matching expressions do not include any bracketing constructs "(...)" containing expressions that matched .

      That's not an elegant statement, and it may be more confusing than helpful, but it avoids the suggestion that an unsuccessful match might change the match variables ($1, $2, etc.).