Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

${^MATCH} regex special variable(s) and /p regex modifier

by AnomalousMonk (Archbishop)
on Oct 04, 2011 at 00:47 UTC ( #929430=perlquestion: print w/replies, xml ) Need Help??

AnomalousMonk has asked for the wisdom of the Perl Monks concerning the following question:

I'm confused about the behavior of the special match variables  ${^PREMATCH} ${^MATCH} ${^POSTMATCH} (see perlvar) in relation to the /p regex modifier, all available in 5.10+. (Note that these are not, AFAIU, the same as the  $PREMATCH $MATCH $POSTMATCH variables (again, perlvar), which are just the  use English; equivalents of the  $` $& $' variables, the notorious '$& and friends'.)

The documentation leads me to believe that  ${^MATCH} et al are only valid after a match that uses the /p regex modifier, but the code below produces the same output with or without the /p modifier. What gives?

>perl -wMstrict -le "my $s = '----abc123++++'; $s =~ m{ ([[:alpha:]]+) (\d+) }xms; print qq{'${^PREMATCH}' '${^MATCH}' '${^POSTMATCH}' ($1) ($2)}; " '----' 'abc123' '++++' (abc) (123)

Replies are listed 'Best First'.
Re: ${^MATCH} regex special variable(s) and /p regex modifier
by toolic (Bishop) on Oct 04, 2011 at 01:32 UTC
    Here is a quote from perlvar:
    This is similar to $& ($MATCH ) except that it does not incur the performance penalty associated with that variable, and is only guaranteed to return a defined value when the pattern was compiled or executed with the /p modifier.
    I think the key word there is "guaranteed". It seems like the variable gets defined even if /p is not used, although it is not explicitly mentioned. To be safe, I would always use /p when you want those variables.

    If you feel the docs should be modified, submit a patch via perlbug.

Re: ${^MATCH} regex special variable(s) and /p regex modifier
by JavaFan (Canon) on Oct 04, 2011 at 07:03 UTC
    That's because you are using parenthesis. Using parens mays you're paying "the penalty" (for that match) anyway. So, you get ${^PREMATCH}, ${^MATCH}, and ${^POSTMATCH} for "free".

    Try running your match without parens, and see the difference.

      Try running your match without parens, and see the difference.
      I tried without parens and saw no difference. I tried with perl 5.14.1 and 5.12.2.
        With 5.12.2:
        $ perl -wE 'my $s = "foo bar"; $s =~ /(bar)/; say ${^PREMATCH}' foo $ perl -wE 'my $s = "foo bar"; $s =~ /bar/; say ${^PREMATCH}' Use of uninitialized value $^PREMATCH in say at -e line 1. $
        Note also the difference in what's going on:
        $ perl -Mre=debug -wE 'my $s = "foo bar"; $s =~ /bar/;' Compiling REx "bar" Final program: 1: EXACT <bar> (3) 3: END (0) anchored "bar" at 0 (checking anchored isall) minlen 3 Guessing start of match in sv for REx "bar" against "foo bar" Found anchored substr "bar" at offset 4... Starting position does not contradict /^/m... Guessed: match at offset 4 Freeing REx: "bar" $ perl -Mre=debug -wE 'my $s = "foo bar"; $s =~ /(bar)/;' Compiling REx "(bar)" Final program: 1: OPEN1 (3) 3: EXACT <bar> (5) 5: CLOSE1 (7) 7: END (0) anchored "bar" at 0 (checking anchored) minlen 3 Guessing start of match in sv for REx "(bar)" against "foo bar" Found anchored substr "bar" at offset 4... Starting position does not contradict /^/m... Guessed: match at offset 4 Matching REx "(bar)" against "bar" 4 <foo > <bar> | 1:OPEN1(3) 4 <foo > <bar> | 3:EXACT <bar>(5) 7 <foo bar> <> | 5:CLOSE1(7) 7 <foo bar> <> | 7:END(0) Match successful! Freeing REx: "(bar)" $
Re: ${^MATCH} regex special variable(s) and /p regex modifier
by AnomalousMonk (Archbishop) on Oct 05, 2011 at 06:11 UTC

    Following the replies of JavaFan and lidden, I tried matching against the string 'foo 123 bar' in Strawberries 5.10.1 and 5.12.3. I found that without the /p modifier  /(123)/ and  /\d+/ 'correctly' assigned to all the  ${^MATCH} variables and  /123/ did not. (All these regexes assign as expected when the /p modifier is used.)

    I guess the take-away lesson here is toolic's emphasis on the word 'guaranteed' in the documentation: it really does mean what it says. I'm of two minds about submitting a patch request for the docs. On one hand, the current documentation states simply and clearly what is guaranteed and the conditions of the guarantee. On the other hand, I have a compulsion to warn that without the protection of the /p modifier, there are situations in which the  ${^MATCH} variables may seem to work properly without, in fact, doing so reliably; i.e., one may spend the day ambling very enjoyably through the jungle, then suddenly find oneself standing in a ten foot deep hole with a five foot bamboo stake up a very sensitive place. Must think on this.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://929430]
Approved by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (7)
As of 2023-11-28 13:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?