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