merlyn's code doesn't really do the same thing as mkmcconn's code. He checks for a good $base or a good $ext.

mkmcconn's code is actually looking for a good $base explicitly. Assuming this is the intended behavior, the code should look like this:

# mkmcconn meaning here:
while (<DATA>) { # not "for"... no need to suck all into memory
    (my ($base, $ext) = /(\w+)\.(tiff?)\b/)
    if ($base) {
      # we have a good $base
    }
  }

# merlyn style here
while (<DATA>) { # not "for"... no need to suck all into memory
    if (my ($base, $ext) = /(\w+)\.(tiff?)\b/) {
      # we have a good $base or $ext
    }
  }
[download]

It is possible to squeeze the check for $base's validity into the same line with the declaration and assignment, but I couldn't think of a way to do it that wasn't ugly. Perhaps someone more skilled than I can think of a way.

Thanks to mkmcconn for pointing out the cool way to use regexes, and to merlyn for the elegant restatement of the script.

Update TGI removes foot from mouth and attempts to put it right back in. If I am not completely confused the distinction would need to be made if either parenthetical in the regex could match a null value. Like (\d*). If you do get a null match, are the $\d variable assignments unaffected? How about assigning into a list, are the undefined values dropped? Not that I thought of this before I posted, I didn't get that the match value had to be 0 or 2.

Update 2 I didn't have time to check the questions I asked yesterday, but I did this morning. Lookout below and you'll get to see what happens with NULL behavior.

@strings=('aaaaaa','11111aaaaa');
foreach (@strings)
{   my $ord = (my ($number, $letter) = /(\d*)([a-zA-Z]+)/);
    print "$_\n";
    print "\tORD = $ord\tNUM = $number\tLET = $letter\n";
}
[download]

Results:

aaaaaa
        ORD = 2 NUM =   LET = aaaaaa
11111aaaaa
        ORD = 2 NUM = 11111     LET = aaaaa

merlyn's code uses the feature of list assignment in scalar context. This returns the number of elements being returned, which, in this case, is either 0 or 2. If the regex matches, then it returns $1 and $2, which means that $base and $ext get their values.

If the regex matches, then the two variables have values -- one can not be defined if the other isn't. Thus, merlyn's code does the right thing.

japhy -- Perl and Regex Hacker

Actually, it's not "or", it's "and". I'm checking for both a good $base and $ext implicitly, or rather, I don't need to check. If the regex matches, both $base and $ext will be set properly. If the regex fails, the match list length is 0, and the if fails.

-- Randal L. Schwartz, Perl hacker