curious regex result for perl 5.8.8

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

Consider the following program which just does a regex on two array entries:

@files=("zzz.21.yy.ccc", "zzz.220.ccc" );

foreach $name (@files)
  {
  chomp $name;
    $match="no ";
    $match="yes" if ( $name =~ /(^[a-z]{3})\.(\d{2,3})\..*\.ccc/) ;
    print "$match, $name, match1: $1, match2: $2\n";
  }
[download]

When I run this on Linux perl 5.8.8 $2 does not seem correct for the second name:

The second name should have the same values since the regex match fails the second time, but $2 mysteriously takes "21." from the first entry. Can this be a problem with perl 5.8.8?

See below:

perl issueWithRegex.pl 
yes, zzz.21.yy.ccc, match1: zzz, match2: 21
no , zzz.220.ccc, match1: zzz, match2: 21.
[download]

With perl 5.10.1 this seems to run as I would expect it to:

perl issueWithRegex.pl
yes, zzz.21.yy.ccc, match1: zzz, match2: 21
no , zzz.220.ccc, match1: zzz, match2: 21
[download]

Thanks for any comments.

Comment on curious regex result for perl 5.8.8 Select or Download Code

Replies are listed 'Best First'.
Re: curious regex result for perl 5.8.8 by GrandFather (Saint) on Jun 20, 2016 at 22:53 UTC
If there is no match the content of the capture variables is bogus. The fact that their content is a different value of bogus between different versions of Perl is not so important as the fact that the value is not defined when there is no match. Your code would be better written: `use strict; use warnings; my @files = ("zzz.21.yy.ccc", "zzz.220.ccc"); foreach my $name (@files) { chomp $name; if ($name =~ /(^[a-z]{3})\.(\d{2,3})\..*\.ccc/) { print "yes, $name, match1: $1, match2: $2\n"; } else { print "no, $name\n"; } }` [download] Prints: `yes, zzz.21.yy.ccc, match1: zzz, match2: 21 no, zzz.220.ccc` [download] Premature optimization is the root of all job security	[reply] [d/l] [select]
Re^2: curious regex result for perl 5.8.8 by dave_the_m (Monsignor) on Jun 21, 2016 at 10:01 UTC
If there is no match the content of the capture variables is bogus That's not strictly accurate. The capture variables reflect the last successful match, where that match is dynamically scoped. The 5.8.x behaviour was a bug, fixed in 5.10.0 by commit c74340f9cdee. Dave.	[reply]
Re^3: curious regex result for perl 5.8.8 by GrandFather (Saint) on Jun 22, 2016 at 02:02 UTC
"That's not strictly accurate." Oh yes it is, probably! If there was no match then it's easy to argue that there should be no capture. If there was no capture the contents of the capture variables should be undef. The current "last capture" behavior then can easily and accurately be described as bogus. :-) I can understand that there are compelling (probably historical compatibility) reasons for the current behavior. In a big picture sense that doesn't make the behavior less bogus. Besides, bogus is a fun word so I like to use it - what's bogus with that? Premature optimization is the root of all job security	[reply]
Re^4: curious regex result for perl 5.8.8 by Anonymous Monk on Jun 22, 2016 at 02:15 UTC
Re^5: curious regex result for perl 5.8.8 by GrandFather (Saint) on Jun 22, 2016 at 04:13 UTC
Re: curious regex result for perl 5.8.8 by Cristoforo (Curate) on Jun 20, 2016 at 22:52 UTC
From the docs for perlre NOTE: Failed matches in Perl do not reset the match variables . . . You can see this more clearly with a slightly modified version of your code where the leading characters are 'xxx' instead of 'zzz'. `my @files=("zzz.21.yy.ccc", "xxx.220.ccc" ); foreach my $name (@files) { my $match="no "; $match="yes" if ( $name =~ /(^[a-z]{3})\.(\d{2,3})\..*\.ccc/) ; print "$match, $name, match1: $1, match2: $2\n"; }` [download] The variables $1 and $2 retain the values they had on the previous successful match. `yes, zzz.21.yy.ccc, match1: zzz, match2: 21 no , xxx.220.ccc, match1: zzz, match2: 21` [download]	[reply] [d/l] [select]
Re^2: curious regex result for perl 5.8.8 by BillKSmith (Monsignor) on Jun 21, 2016 at 02:03 UTC
The same fact is also documented in a slightly different way in the second sentence of Variables related to regular expressions. Bill	[reply]
Re: curious regex result for perl 5.8.8 by Anonymous Monk on Jun 20, 2016 at 22:38 UTC
What happens when you explicitly specify /s or /m (as in m//s or m//m)? What do you observe as the difference between those two old perl versions under `use re 'debug';` or rxrx? Can this be a problem with perl 5.8.8? If you have to ask the answer is no :)	[reply] [d/l]