I failed to make my point: I think it is to do with the array is being forced to a scalar,
i.e. look at the loop, not the regex :)
Yoda: "work-arounds, crufts, kludges...the dark side are they. Easily
+they flow, quick to join you in times of trouble.
Luke: "Is the dark side more powerful?"
Yoda: "No..no....no, quicker, easier, more seductive"
Luke: "How am I to know the good side from bad?"
Yoda: "Once you start along the dark path, forever will it cloud your
+change requests"
--
Brother Frankus.
Edit 2001-03-20 by tye (changed <pre> to <code>) | [reply] [d/l] [select] |
I'll take a crack at this one, since it gave me the same kind of problems when I started using regexps as loop controls. Using brother frankus' example :
$_='axxbcaxbagaxbacba';
foreach my $a (m/a(.*?)b/g) {
print "$a\n";
}
OK, so, from perlman :
The foreach modifier is an iterator: For each value in EXPR, it aliases $_ to the value and executes the statement
So, right away, we see that foreach doesn't care about, or understand $1 and company at all. It only knows about its control variable ($a, in this case) and its list : (m/a(.*?)b/g).
So what's the for statement's list? It's generated from m/a(.*?)b/g. And, as perlop states,
(m//) ... in a list context returns a list consisting of the subexpressions matched by the parentheses in the pattern, i.e., ($1, $2, $3...)
So, with this regexp, you get an anonymous list of 4 elements. It's like writing foreach my $a ($1, $2, $3, $4) {
by the time the code in the loop's running, the regexp has run and returned a list of values that foreach will process.
I hope that makes things a little clearer, this gave me trouble for a while, and hopefully this explanation will minimize the trouble it gives you.
update see below... sometimes convenient variables aren't good for practical use.
| [reply] [d/l] [select] |
| [reply] [d/l] [select] |