It's by design. There's an implicit local for match variables in blocks.
And re "reliability": a regexp that doesn't match will not affect the match variables, they will not (necessarily) be undef, but the value they got on the last succesful regexp — with the above caveat. | [reply] |
That doens't quite explain it. It the first loop, it's as if the implicit local $& is outside of the loop — It prints 'bar' on the 'baz' pass of the loop — while in the second loop, it's as is the implicit local $& is inside of the loop.
Could
print "$&\n" unless /bar/;
suffer from a problem similar to the one from which
my ... if ...;
suffers?
| [reply]
[d/l]
[select] |