in reply to Weird bug with qr// and named capture buffers? Or just me?

If you don't specify it on the m//, s/// or qr// that builds a regexp, ^ and $ will act as if you didn't specify it. Absence of "m" does not mean "inherit". For that reason, qr// without "m" turns off the option for the regexp it builds.

>perl -le"print qr/foo/" (?-xism:foo) >perl -le"print qr/foo/m" (?m-xis:foo)

Until very recently, there was a bug that caused (?-m:...) to be ignored in some circumstances.

>perl588 -le"$re=qr/a$/; print $re; print qq{a\nb\n}=~/$re/m ?1:0" (?-xism:foo$) 1 >perl5100 -le"$re=qr/a$/; print $re; print qq{a\nb\n}=~/$re/m ?1:0" (?-xism:foo$) 0

Replies are listed 'Best First'.
Re^2: Weird bug with qr// and named capture buffers? Or just me?
by Latro (Novice) on Jun 18, 2008 at 05:31 UTC

    Oh! I see, it makes sense. The perlop page says that if you use the options on the qr// and then interpolate the variable on a bigger string on the m// , the options (msi....) get set for the whole thing too.

    But it makes sense as you say, that if m wasnt specified when using the qr//, the resulting compiled regex will not "accept" it later at the m//

    So yes, it is my fault and trivial - even if a bit obscure, it should have dawned to me before. It is "compiled", after all :-) Thanks!

      I'll let the developers know about the bad docs.
Re^2: Weird bug with qr// and named capture buffers? Or just me?
by packy (Initiate) on Jun 09, 2009 at 19:52 UTC
    We just bumped into this in our codebase, and I've heard rumor that there's a patch somewhere to 5.10 that generates a warning if someone attempts to use a modifier on an already compiled regexp. Is this just a rumor?