On Mon, Aug 13, 2001 at 05:57:13PM -0400, Greg London wrote:
> Ronald J Kimball wrote:
>
> > m//g only sets pos() when it's in scalar context. I don't think pos()
> > would generally be useful after a match in list context.
>
> argh. That's exactly how I want to use it. I have a subroutine that
> receives a pattern and then does a regexp with the pattern.
> it doesn't know if the pattern contains parens, so I wanted to capture
> the results using list context and just pass the array back.
You have discovered the serious flaw in the design of m//. :/ It behaves
differently depending on whether it is scalar or list context, and it also
behaves differently depending on whether the pattern contains parentheses
or not.
I recall an extensive thread in clpm about this issue. Perhaps I can dig
it up...
I'm not sure why you need pos() for this, though.
> unfortunately, $1, $2, $3, etc, is not exactly easy to code in a generic
> way.
> there doesn't happen to be a global array that corresponds to:
> @GLOBAL::MATCHES($1, $2, $3, $4, $5, $6, ...);
>
> or some such thing? would I be that lucky?
Nope, I'm afraid not.
> hey, can we slide this into perl6 if it isn't in there now?
Someone else will have to answer that. :)
> > Note that your second example actually prints whatever pos() was set to
> > before the match in list context; the list context match doesn't affect
> > pos() at all.
>
> ???
>
> I get undef on the second example:
>
> my $hstr1 = "fee fie foe foo";
> $hstr1 =~ m/e/mcg;
> print "position is ".pos($hstr1)."\n";
>
> my $hstr2 = "fee fie foe foo";
> my @matches = $hstr2 =~ m/e/mcg;
> print "position is ".pos($hstr2)."\n";
>
> gives me this output:
>
> position is 2
> Use of uninitialized value in concatenation (.) at .//junk.pl line 11.
> position is
pos($hstr2) *was* undef before the list context match. Try performing both
matches on $hstr1, and printing out pos($hstr1) in both cases.
Ronald