[sf-perl] Using the bistable .. op and regexps

[Garth Webb]

Perl doesn't reset these variables if the regex doesn't match which is why
you always have to test whether the regex was true before  using $1, $2,
etc.  From http://perldoc.perl.org/perlre.html:

*NOTE*: Failed matches in Perl do not reset the match variables, which makes
it easier to write code that tests for a series of more specific cases and
remembers the best match.

In your case the range operator as a whole remains true even while the LHS
is false which is why you have to rewrite it the way you did.

Garth

2010/9/16 yary <not.com at gmail.com>

> Hi all,
>
> I'm going through logs seeing if a change improved a particular SQL
> statements execution time. The part I'm interested looks like this:
>
>  insert into foo..bar_440_5678_D
>  select
>        a.pd,
>        a.tg,
>  ....
>  Elapsed time: 0m27.485s
>
> I'm interested in the "5678" and the time it took. Seems like the flip-flip
> ".." is perfect for a quick hack to extract that info:
>
> perl -ne 'if(/insert into foo\.\.bar_440_(\d+)/../time: (.+)/&&$1){print
> "$1\n"}' SQL.log
>
> The thing is, it prints "5678" many times, until it gets to the "Elapsed
> time" portion. I would expect that the lines between the start and the end,
> which don't match, to clear $1.
>
> I ended up with a longer one-liner to extract the info I was looking for-
>
> perl -ne 'if(((/insert into foo\.\.bar_440_(\d+)/ and $a=$1)..(/time: (.+)/
> and $b=$1))&&$b){print "$a took $b\n";$b=0}' SQL.log
>
> Now I'm curious why I couldn't rely on $1 being undefined for the
> intermediate lines. Anyone have a good explanation?
>
> -y
>
>
>
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20100916/b1f41eac/attachment.html>