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
Keeping track of 'Unescaped left brace in regex is deprecated' #12137
Comments
From @andkThis ticket could serve as a meeting point for authors affected. I'll The commit itself describes the change very well, so there may be The commit itself http://perl5.git.perl.org/perl.git/commit/2a53d3314d380af5ab5283758219417c6dfa36e9 The first fail reports DRTECH/HTML-StripScripts-1.05.tar.gz HMBRAND/Data-Peek-0.37.tgz HMBRAND/Spreadsheet-Read-0.46.tgz JAK/File-ANVL-1.04.tar.gz JSTEBENS/POE-Component-Server-REST-1.11.tar.gz JUSTER/WWW-AUR-0.14.tar.gz KJETILK/RDF-Trine-Node-Literal-XML-0.16.tar.gz KRYDE/Perl-Critic-Pulp-70.tar.gz KRYDE/distlinks-5.tar.gz MAROS/Business-UPS-Tracking-1.09.tar.gz MONS/XML-RPC-Fast-0.8.tar.gz SDPRICE/App-Framework-Lite-1.08.tar.gz WARRINGD/Elive-1.26.tar.gz perl -V Summary of my perl5 (revision 5 version 17 subversion 0) configuration: Characteristics of this binary (from libperl): -- |
From @khwilliamsonOn 05/26/2012 02:59 AM, (Andreas J. Koenig) (via RT) wrote:
This new deprecation message appears to have exposed a real bug in this # Failed test 'use HTML::StripScripts;' |
The RT System itself - Status changed from 'new' to 'open' |
From @clintongormley
... which embarrassingly wasn't being tested either. thanks! clint |
From @andkFound in GRANTM/XML-Simple-2.18.tar.gz in lib/XML/Simple.pm: 995 $val =~ s{\$\{([\w.]+)\}}{ $self->get_var($1) }ge; % make test Look like perl miscounts one backslash. I would expect that the regexp -- |
From @cpansproutOn Mon May 28 00:51:00 2012, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
I think this pretty much ends this deprecation. Too many people use {} What’s happening above is that delimiter escapes are removed before that The same thing happens with m.\.., which is equivalent to /./, not /\./. If one is using {} delimiters, then there is no way to match a literal { On the other hand, m{ a\{1,2\} }x doesn’t do what most people think it does. -- Father Chrysostomos |
From @demerphqOn 28 May 2012 17:45, Father Chrysostomos via RT
Well, we could fix how this is handled. But one wonders if its worth Yves -- |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
Not at all. It's an especially confusing case, especially deserving of
Maybe there should be a warning for every use of a backslashed -zefram |
From @hvdsandreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) wrote: IIRC, when you use a regex metacharacter as a delimiter, escaping it % perl -wle 'print "line\n" =~ m$\$$' So I think the warning is correct, though somewhat misleadingly expressed. I don't remember if there is a way to get past that to match the literal. Hugo |
From @demerphqOn 28 May 2012 20:31, Zefram <zefram@fysh.org> wrote:
The alternative is to stop the tokenizer from doing this type of Yves -- |
From @ikegamiOn Mon, May 28, 2012 at 11:45 AM, Father Chrysostomos via RT <
Wow. That's unexpected! I would call it a bug even. |
From vadim.konovalov@alcatel-lucent.comOn Mon, May 28, 2012 at 11:45 AM, Father Chrysostomos via RT <perlbug-followup@perl.org<mailto:perlbug-followup@perl.org>> wrote: Wow. That's unexpected! I would call it a bug even. not a bug. |
From vadim.konovalov@alcatel-lucent.com
wow. that's tough. I use s{}{}ge often, and then escape any { and } by \, which AFAIR I saw this somewhere in perl documentation and got used So - there are many constructs of type - Please do not deprecate this. Having "{}" delimeters is fun and
This is fine, and meets my expectations.
please don't |
From @ikegamiOn Tue, May 29, 2012 at 12:49 AM, Konovalov, Vadim (Vadim)** CTR ** <
The escape doesn't escape! How is that not a bug? |
From @demerphqOn 29 May 2012 07:17, Eric Brine <ikegami@adaelis.com> wrote:
Because it is documented to happen. Yves -- |
From vadim.konovalov@alcatel-lucent.com
And also, it escapes the delimeters, which is what I do expect. regards, |
From @ikegamiOn Tue, May 29, 2012 at 1:26 AM, demerphq <demerphq@gmail.com> wrote:
Where? If so, it directly contradicts perlre. "Quote the next metacharacter." "So anything that looks like \\, \(, \), \<, \>, \{, or \} is always "Any single character matches itself, unless it is a metacharacter with a |
From @demerphqOn 29 May 2012 07:45, Konovalov, Vadim (Vadim)** CTR **
Sorry? No. The tokenizer *unescapes* the delimiters. There is NO way Yves -- |
From @demerphqOn 29 May 2012 08:23, Eric Brine <ikegami@adaelis.com> wrote:
I posted the relevent docs in the mail titled "Oh dear, maybe we have The lack of processing of "\\" creates specific m m ^ a \s* b mmx; In the RE above, which is intentionally obfuscated for While documented I do think the behavior is undesirable and I think Yves -- |
From vadim.konovalov@alcatel-lucent.com
I am not talking about tokenizer, I just see that '\' escapes a dot in m.\... On the other side, escaping by '\' in replacement part of the Regards, |
From @demerphqOn 28 May 2012 20:31, Zefram <zefram@fysh.org> wrote:
I dont think that is really a good idea. It would have to be handled I think we should "just" disentangle the regex parsing from normal cheers, -- |
From @demerphqOn 29 May 2012 08:38, Konovalov, Vadim (Vadim)** CTR **
I dont think you are understanding this issue properly. What you just perl -le'$_="x"; s/x/\//; print' does NOT pass through '\/' to the regex engine. You can pass "\\/" Yves -- |
From @TuxOn Mon, 28 May 2012 19:19:25 +0100, hv@crypt.org wrote:
Got this report this morning: http://www.cpantesters.org/cpan/report/b40c2a9c-a87e-11e1-85e6-b1e975b706df t/11_DDumper.t .... ok # Failed test 'no warnings' code that causes it SKIP: { I just added the \ before the { as it passes on 5.8.0 up to blead (64 -- |
From @ikegamiOn Tue, May 29, 2012 at 2:34 AM, demerphq <demerphq@gmail.com> wrote:
(did noone see that?) But here it is again.. I understand why it behaves the way it does.
with the subheading:"RE" in "?RE?", "/RE/", "m/RE/", "s/RE/foo/": Ah, so there is some disagreement, then. perlre says it is required for - Eric |
From @cpansproutOn Mon May 28 23:42:13 2012, demerphq wrote:
But \ does escape the delimiter in that it stops it from being -- Father Chrysostomos |
From @hvdsdemerphq <demerphq@gmail.com> wrote: It occurs to me that we could draw a useful distinction between balanced I think <> are the only balanced delimiters used in an unbalanced way Of course that would involve a) disentangling at least some of the work I'm not really sure how much work this would be, however. Hugo |
From @demerphqOn 29 May 2012 09:27, <hv@crypt.org> wrote:
I plan to look into it. Your analysis is much appreciated. Yves -- |
From @khwilliamsonThe example below uses single quotes as qr delimiters On 05/29/2012 12:42 AM, H.Merijn Brand wrote:
Bug #21491 says that single quotes should not interpolate. But this I wonder how much code is out there that depends on #21491 being broken. |
From @cpansproutOn Fri Jun 01 14:40:56 2012, public@khwilliamson.com wrote:
Yes, and it would diverge from the long-documented behaviour: Customary Generic Meaning Interpolates * unless the delimiter is ''.
Yes, and not-a-bug. -- Father Chrysostomos |
From @cpansproutOn Fri Jun 01 17:57:55 2012, sprout wrote:
Sorry, I was a little confused. The reason for it not being a bug is that, if m '\n' stops matching -- Father Chrysostomos |
From @demerphqOn 2 June 2012 03:01, Father Chrysostomos via RT
That doesnt make sense. Single quotes for ack are a shell quoting Yves -- |
From @cpansproutOn Sat Jun 02 02:07:11 2012, demerphq wrote:
Either way, the regular expression engine itself has to interpret \n. -- Father Chrysostomos |
From @demerphqOn 2 June 2012 14:29, Father Chrysostomos via RT
Its cant rely on the tokenizer to resolve it no. That is a general Yves -- |
From @rjbs* Karl Williamson <public@khwilliamson.com> [2012-06-01T17:40:18]
This very naive CPAN search indicates "not much." http://grep.cpan.me/?q=qr%27%5B%5E%27%5Cn%5D%2B%5C%24%5B%5E%27%5D&page=2 I think that bug should still be fixed. -- |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-06-02T08:29:07]
My understanding is that the regular expression engine has its own machinery I could be wrong. Somebody tell me. -- |
From @cpansproutOn Mon Jun 04 16:52:26 2012, perl.p5p@rjbs.manxome.org wrote:
That’s right, which is why "\n" =~ '\n' matches, and why "\n" =~ m'\n' -- Father Chrysostomos |
From @demerphqOn 5 June 2012 01:51, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
I already said this was the case. The regex engine cannot depend on Tokenizer does nothing: $ perl -Mre=debug -e'/\n/' Tokenizer does something: $ perl -Mre=debug -e'my $x="\n"; /$x/' Notice the difference? Yves -- |
From @demerphqOn 1 June 2012 23:40, Karl Williamson <public@khwilliamson.com> wrote:
Are you sure about that? I don't see any interpolation there. Do you As far as I understand things \\ and \' are *supposed* to be unescaped So what do you mean by this? I see nothing unexpected here. Yves -- |
From @rjbs* demerphq <demerphq@gmail.com> [2012-06-05T02:12:29]
I was confused by this, too, and foolishly didn't go read 21491. This is about Yes, fixing this looks like it would break the world. In fact, I think the -- |
From @demerphqOn 5 June 2012 14:26, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
Arent the case that Karl mentioned and the case in the bug different? The case in the bug comes down to this: my $pat= "\\n"; print "\n"=~/$pat/; Which matches, because the toker first turns "\\n" into "\n" and then This behaviour has changed over time and the docs should probably
Well, I can argue the case of: $x="\\n"; "\n"=~/$x/, but the case of Yves -- |
From @rurbanThis is a bug report for perl from rurban@cpanel.net, From a375e6bcfaaf64bae9ab3e153f1721225d6ae631 Mon Sep 17 00:00:00 2001 cpan/ExtUtils-MakeMaker/t/MM_OS2.t | 2 +- Inline Patchdiff --git a/cpan/ExtUtils-MakeMaker/t/MM_OS2.t b/cpan/ExtUtils-MakeMaker/t/MM_OS2.t
index 4d88e85..2997541 100644
--- a/cpan/ExtUtils-MakeMaker/t/MM_OS2.t
+++ b/cpan/ExtUtils-MakeMaker/t/MM_OS2.t
@@ -42,7 +42,7 @@ delete $mm->{SKIPHASH};
my $res = $mm->dlsyms();
like( $res, qr/baseext\.def: Makefile/,
'... without flag, should return make targets' );
-like( $res, qr/"DL_FUNCS" => { }/,
+like( $res, qr/"DL_FUNCS" => \{ }/,
'... should provide empty hash refs where necessary' );
like( $res, qr/"DL_VARS" => \[]/, '... and empty array refs too' );
diff --git a/lib/DB.t b/lib/DB.t
index a1fadf3..cdb6583 100644
--- a/lib/DB.t
+++ b/lib/DB.t
@@ -126,7 +126,7 @@ is( DB::_clientname('bar'), undef,
my @ret = eval { DB->backtrace() };
like( $ret[0], qr/file.+\Q$0\E/, 'DB::backtrace() should report current file');
like( $ret[0], qr/line $line/, '... should report calling line number' );
- like( $ret[0], qr/eval {...}/, '... should catch eval BLOCK' );
+ like( $ret[0], qr/eval \{...}/, '... should catch eval BLOCK' );
@ret = eval "one(2)";
is( scalar @ret, 1, '... should report from provided stack frame number' );
--
Flags: Site configuration information for perl 5.17.1: Configured by rurban at Tue Jun 5 09:12:24 CDT 2012. Summary of my perl5 (revision 5 version 17 subversion 1) configuration: Locally applied patches: @INC for perl 5.17.1: Environment for perl 5.17.1: |
From @trwyantThe ExtUtils-MakeMaker and DB warnings reported by Reini Urban are still |
From @trwyantInteresting thing found under 5.17.2: $ perl -E 'm{ \$ \{ }x' Is this a weird bug in the escape code, or am I missing something? |
From rmbarker.cpan@btinternet.comOn Sat, 2012-07-21 at 07:26 -0700, Tom Wyant via RT wrote:
The latter is fixed by 7150f91 |
From @khwilliamsonOn 07/21/2012 11:44 AM, Robin Barker wrote:> I suggest this bug is
OK, moving it to the 113094 On 07/21/2012 07:51 AM, Dave Mitchell wrote:
Correct me if I'm wrong, but I believe that the most encompassing change Obviously, if we decided to, we could restrict the change to just '{', |
From @iabynOn Sat, Jul 21, 2012 at 12:42:07PM -0700, Karl Williamson via RT wrote:
Correct. It's only cases where a regex metacharacter is used a delimiter,
My own opinion is that quoting for literal patterns is already complex -- |
From @cpansproutOn Sat Jul 21 12:42:06 2012, khw wrote:
Punctuation variables. In a match-once pattern, I can refer to Anyway, if the interpretation of escaped delimiters is going to change q n\nn =~ m n\nn; Also, please take m?fo\?? into account. I would have to rewrite that -- Father Chrysostomos |
From @khwilliamsonOn 07/22/2012 03:30 AM, Dave Mitchell wrote:
It is currently quite possible to make an easily overlooked error in We also have a need going forward to be able to specify new One option is to say that this new rule applies only to balanced Another option would be to have an optional feature enabled under 'use Two other options I've mentioned previously are to abandon any work in Other option ideas are welcome. Here is what I found with grepping cpan Left brace as a delimiter: { yielded no problems, as previously reported. Less-than sign as a delimiter: < I found no examples where this would be a problem. There is one Regexp-NamedCaptures-0.05/lib/Regexp/NamedCaptures.pm { type => SCALAR, But the meaning is unchanged. Left paren as a delimiter: ( (returned only false positives. The regex is more complicated because Left bracket as a delimiter: [ yielded a single potential problem: perl-5.15.6/ext/B/t/OptreeCheck.pm # symbolic hints from the golden results. |
From @iabynOn Thu, Jul 26, 2012 at 10:51:46AM -0600, Karl Williamson wrote:
I think I like the idea of a deprecation cycle. But have quite a long cycle; e.g. two major releases that have the -- |
From @khwilliamsonCommit e62d0b1 reverts the offending commit Instead, commit4d68ffa0f7f345bc1ae6751744518ba4bc3859bd implements a -- |
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#113094 (status was 'resolved')
Searchable as RT113094$
The text was updated successfully, but these errors were encountered: