http://www.perlmonks.org?node_id=463543


in reply to Re^4: Regexes: finding ALL matches (including overlap)
in thread Regexes: finding ALL matches (including overlap)

Is there any way to rationalize the actual behavior without diving too deeply into the Perl internals?

Its very simple: it's a bug. (In an experimental feature.) Basically the way perls regex engine handles embedded code is subtly wrong in a number of ways. One aspect of this is that you should never use lexicals inside of regexes inside of a repeatable scope (such as the body of a loop or a subroutine). If you are doing a one off it will probably work as you expect, but as soon as you stick the code in a subroutine or something like that and call it twice things dont work out properly. The simple workaround as blokhead explained is to use package level variables and local.

#!perl -l use strict; use warnings; { # BAD for my $i (0..1) { my $count=0; 'abc'=~/.*(?{$count++})(??{'\\z\\A'})/; print "$i:$count"; } } { # Work around #1, single lexical my $count; for my $i (0..1) { $count=0; 'abc'=~/.*(?{$count++})(??{'\\z\\A'})/; print "$i:$count"; } } { # Work around #2, global explicitly named for my $i (0..1) { local $::count=0; 'abc'=~/.*(?{$::count++})(??{'\\z\\A'})/; print "$i:$::count"; } } { # Work around #3, global our $count; # or use vars qw/$count/; for my $i (0..1) { local $count=0; 'abc'=~/.*(?{$count++})(??{'\\z\\A'})/; print "$i:$count"; } }

I beleive dave_the_m has intentions of fixing this one day. But until then pay careful attention to the fact that embedded code is advertised as provisional and experimental which means that you can't really cry too much when it breaks.

---
$world=~s/war/peace/g