in reply to curious regex result for perl 5.8.8

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

Replies are listed 'Best First'.
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]
      "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]
        yeah , traditions are totally bogus, on ward python soldiers ...
[reply]

In Section Seekers of Perl Wisdom