New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
\Q buggy, eg /x on \Q#foo\E doesn't match '#foo', # becomes special #13257
Comments
From @bulk88Created by @bulk88Following perlre, I used \Q\E to escape things from /x. _______________________________________________ ______________________________________________ I don't know what the correct behavior here, and if there is a doc problem here or a regexp bug or what but something has to change. Tested with Perl 5.12.3 and Perl 5.19.4. Perl Info
|
From @nwc10On Sun, Sep 15, 2013 at 12:44:18AM -0700, bulk88 wrote:
Nice bug. I'm not sure if the behaviour is as simple as # being a "dead" $ perl -e 'warn "a# " =~ /\Qa# \E/ ? "M" : "."' It seems to be have happened between 5.000 and 5.001 $ ./perl -e 'warn "a# " =~ /\Qa# \E/ ? "M" : "."' bisect.pl --target miniperl --start=perl-5.000 --end=perl-5.001 -e 'if ("a#b" !~ /\Qa#b\E/x) { exit 1 }' reports: commit 748a930 The symptom may relate to the code referred to by this entry in its Changes: +NETaa13369: # is now a comment character, and \# should be left for regcomp. but the fact that even back then it differs depending on \E being present or And -Dr suggests something far more screwed up: $ ./perl -Dr -e 'warn "a# " =~ /\Qa# \E/x ? "M" : "."' EXECUTING... String shorter than min possible regex match (3 < 5) It seems that the trailing \E is being left in the string, and then ending up Looks like 5.001 makes exactly the same mistake: $ ./miniperl -Dr -e 'warn "a# " =~ /\Qa# \E/x ? "M" : "."' EXECUTING... . at -e line 1. EXECUTING... 1:BRANCH <a# > EXECUTING... 1:BRANCH <a# >
I think that the implementation is at fault here. In that, conceptually, Nicholas Clark |
The RT System itself - Status changed from 'new' to 'open' |
From @ikegamiOn Wed, Sep 18, 2013 at 10:56 AM, Nicholas Clark <nick@ccl4.org> wrote:
Nice indeed. Easy to see with qr// $re = qr/\Q#abc\E/x; print "$re\n"; print '#abc' =~ /$re/ || 0, "\n"; (?^x:\#abc\\E) |
From @maukeCreated by @mauke% perl -wle 'print "#\\E \\z" =~ / \Q#\E \z/x ? "wtf" : "k"' Compiling REx " \#\\E\ \\z" For some reason the # turns everything after it into literal text instead of a Perl Info
|
From @bulk88On Thu Jul 09 13:33:29 2015, mauke- wrote:
Is this a dup of https://rt-archive.perl.org/perl5/Ticket/Display.html?id=119793 ? -- |
The RT System itself - Status changed from 'new' to 'open' |
From @hvdsOn Fri, 15 Jan 2016 16:56:40 -0800, bulk88 wrote:
Yes, I'll merge them. It's still happening: % perl -Dr -we ' Hugo |
From @khwilliamsonI looked at this a little, and it appears to me that there is a fundamental flaw in how \Q is processed. An example is qr/\Q\N{COLON}/ This evaluates to Final program: which is very wrong. perlop's "Gory Details" says that it looks for the end of a quoting construct, and in my example plus the ones in the ticket, it does find the ending pattern delimiter, but within the pattern, I don't see how it is looking for the end of \Q. In yylex(), it does this: NEXTVAL_NEXTTOKE.ival = OP_QUOTEMETA; And then calls itself recursively. I don't understand the overall picture of lexing, but this appears to me to be setting something up for runtime rather than for continued parsing. It would seem to me that \Q should set up some recursive state, which apparently sublex_push() does. but it isn't. This kind of thing has been hashed over before: Github issue #11145 |
To add another weird case I just found: https://perl.bot/p/5guy5u use strict;
use warnings;
chomp(my $str = <<'EOF');
foo\\"bar
EOF
chomp(my $repl = <<'EOF');
\"
EOF
[$str =~ s/\Q\\"/X/gr, $str =~ s/\Q$repl/X/gr]
It seems that when writing a literal (escaped) backslash after |
Migrated from rt.perl.org#119793 (status was 'open')
Searchable as RT119793$
The text was updated successfully, but these errors were encountered: