Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

[perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated'

 

 

First page Previous page 1 2 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded


demerphq at gmail

Jun 2, 2012, 2:06 AM

Post #26 of 32 (139 views)
Permalink
Re: [perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

On 2 June 2012 03:01, Father Chrysostomos via RT
<perlbug-followup [at] perl> wrote:
> On Fri Jun 01 17:57:55 2012, sprout wrote:
>> On Fri Jun 01 14:40:56 2012, public [at] khwilliamson wrote:
>> > The example below uses single quotes as qr delimiters
>> >
>> > On 05/29/2012 12:42 AM, H.Merijn Brand wrote:
>> > > code that causes it
>> > >
>> > > † †SKIP: {
>> > > † † † †$]<= 5.008001 and skip "UTF8 tests useless in this ancient
>> > perl version", 1;
>> > > † † † †$VAR = "a\x0a\x{20ac}";
>> > > † † † †like (DPeek ($VAR), qr'^PVIV\("a\\(n|12)\\342\\202\\254"\\0\)
>> > \[UTF8 "a\\?n\\x{20ac}"\]',
>> > > † † † † † † † † † † † † † † † † † † † † † † † † † †' $VAR
>> > "a\x0a\x{20ac}"');
>> > > † † † †}
>> >
>> > Bug #21491 says that single quotes should not interpolate. †But this
>> > code assumes that it does. †If we fixed #21491, I believe it would
>> > break
>> > this code, would it not?
>>
>> Yes, and it would diverge from the long-documented behaviour:
>>
>> † † Customary †Generic † † † †Meaning † † †Interpolates
>> † † † '' † † † q{} † † † † †Literal † † † † † † no
>> † † † "" † † †qq{} † † † † †Literal † † † † † † yes
>> † † † `` † † †qx{} † † † † †Command † † † † † † yes*
>> † † † † † † † qw{} † † † † Word list † † † † † †no
>> † † † // † † † m{} † † † Pattern match † † † † †yes*
>> † † † † † † † qr{} † † † † †Pattern † † † † † † yes*
>> † † † † † † † †s{}{} † † †Substitution † † † † †yes*
>> † † † † † † † tr{}{} † †Transliteration † † † † no (but see below)
>> † † † † † † † †y{}{} † †Transliteration † † † † no (but see below)
>> † † † † <<EOF † † † † † † † † here-doc † † † † † †yes*
>>
>> † † † * unless the delimiter is ''.
>>
>> >
>> > I wonder how much code is out there that depends on #21491 being
>> > broken.
>> > † We might have to mark it as won't fix, then.
>>
>> Yes, and not-a-bug.
>
> Sorry, I was a little confused.
>
> The reason for it not being a bug is that, if m '\n' stops matching
> "\n", then $foo =~ $user_pat will stop working if the user enters '\n'.
> †That means ack '\n' wonít work any more.

That doesnt make sense. Single quotes for ack are a shell quoting
issue. ack doesnt see the quotes.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"


perlbug-followup at perl

Jun 2, 2012, 5:29 AM

Post #27 of 32 (147 views)
Permalink
[perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

On Sat Jun 02 02:07:11 2012, demerphq wrote:
> On 2 June 2012 03:01, Father Chrysostomos via RT
> <perlbug-followup [at] perl> wrote:
> > On Fri Jun 01 17:57:55 2012, sprout wrote:
> >> On Fri Jun 01 14:40:56 2012, public [at] khwilliamson wrote:
> >> > The example below uses single quotes as qr delimiters
> >> >
> >> > On 05/29/2012 12:42 AM, H.Merijn Brand wrote:
> >> > > code that causes it
> >> > >
> >> > >    SKIP: {
> >> > >        $]<= 5.008001 and skip "UTF8 tests useless in this ancient
> >> > perl version", 1;
> >> > >        $VAR = "a\x0a\x{20ac}";
> >> > >        like (DPeek ($VAR),
qr'^PVIV\("a\\(n|12)\\342\\202\\254"\\0\)
> >> > \[UTF8 "a\\?n\\x{20ac}"\]',
> >> > >                                                    ' $VAR
> >> > "a\x0a\x{20ac}"');
> >> > >        }
> >> >
> >> > Bug #21491 says that single quotes should not interpolate.  But this
> >> > code assumes that it does.  If we fixed #21491, I believe it would
> >> > break
> >> > this code, would it not?
> >>
> >> Yes, and it would diverge from the long-documented behaviour:
> >>
> >>     Customary  Generic        Meaning      Interpolates
> >>       ''       q{}          Literal             no
> >>       ""      qq{}          Literal             yes
> >>       ``      qx{}          Command             yes*
> >>               qw{}         Word list            no
> >>       //       m{}       Pattern match          yes*
> >>               qr{}          Pattern             yes*
> >>                s{}{}      Substitution          yes*
> >>               tr{}{}    Transliteration         no (but see below)
> >>                y{}{}    Transliteration         no (but see below)
> >>         <<EOF                 here-doc            yes*
> >>
> >>       * unless the delimiter is ''.
> >>
> >> >
> >> > I wonder how much code is out there that depends on #21491 being
> >> > broken.
> >> >   We might have to mark it as won't fix, then.
> >>
> >> Yes, and not-a-bug.
> >
> > Sorry, I was a little confused.
> >
> > The reason for it not being a bug is that, if m '\n' stops matching
> > "\n", then $foo =~ $user_pat will stop working if the user enters '\n'.
> >  That means ack '\n' won’t work any more.
>
> That doesnt make sense. Single quotes for ack are a shell quoting
> issue. ack doesnt see the quotes.

Either way, the regular expression engine itself has to interpret \n.
It can’t rely on m// syntax to resolve it.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113094


demerphq at gmail

Jun 2, 2012, 5:45 AM

Post #28 of 32 (144 views)
Permalink
Re: [perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

On 2 June 2012 14:29, Father Chrysostomos via RT
<perlbug-followup [at] perl> wrote:
> On Sat Jun 02 02:07:11 2012, demerphq wrote:
>> On 2 June 2012 03:01, Father Chrysostomos via RT
>> <perlbug-followup [at] perl> wrote:
>> > On Fri Jun 01 17:57:55 2012, sprout wrote:
>> >> On Fri Jun 01 14:40:56 2012, public [at] khwilliamson wrote:
>> >> > The example below uses single quotes as qr delimiters
>> >> >
>> >> > On 05/29/2012 12:42 AM, H.Merijn Brand wrote:
>> >> > > code that causes it
>> >> > >
>> >> > > † †SKIP: {
>> >> > > † † † †$]<= 5.008001 and skip "UTF8 tests useless in this ancient
>> >> > perl version", 1;
>> >> > > † † † †$VAR = "a\x0a\x{20ac}";
>> >> > > † † † †like (DPeek ($VAR),
> qr'^PVIV\("a\\(n|12)\\342\\202\\254"\\0\)
>> >> > \[UTF8 "a\\?n\\x{20ac}"\]',
>> >> > > † † † † † † † † † † † † † † † † † † † † † † † † † †' $VAR
>> >> > "a\x0a\x{20ac}"');
>> >> > > † † † †}
>> >> >
>> >> > Bug #21491 says that single quotes should not interpolate. †But this
>> >> > code assumes that it does. †If we fixed #21491, I believe it would
>> >> > break
>> >> > this code, would it not?
>> >>
>> >> Yes, and it would diverge from the long-documented behaviour:
>> >>
>> >> † † Customary †Generic † † † †Meaning † † †Interpolates
>> >> † † † '' † † † q{} † † † † †Literal † † † † † † no
>> >> † † † "" † † †qq{} † † † † †Literal † † † † † † yes
>> >> † † † `` † † †qx{} † † † † †Command † † † † † † yes*
>> >> † † † † † † † qw{} † † † † Word list † † † † † †no
>> >> † † † // † † † m{} † † † Pattern match † † † † †yes*
>> >> † † † † † † † qr{} † † † † †Pattern † † † † † † yes*
>> >> † † † † † † † †s{}{} † † †Substitution † † † † †yes*
>> >> † † † † † † † tr{}{} † †Transliteration † † † † no (but see below)
>> >> † † † † † † † †y{}{} † †Transliteration † † † † no (but see below)
>> >> † † † † <<EOF † † † † † † † † here-doc † † † † † †yes*
>> >>
>> >> † † † * unless the delimiter is ''.
>> >>
>> >> >
>> >> > I wonder how much code is out there that depends on #21491 being
>> >> > broken.
>> >> > † We might have to mark it as won't fix, then.
>> >>
>> >> Yes, and not-a-bug.
>> >
>> > Sorry, I was a little confused.
>> >
>> > The reason for it not being a bug is that, if m '\n' stops matching
>> > "\n", then $foo =~ $user_pat will stop working if the user enters '\n'.
>> > †That means ack '\n' wonít work any more.
>>
>> That doesnt make sense. Single quotes for ack are a shell quoting
>> issue. ack doesnt see the quotes.
>
> Either way, the regular expression engine itself has to interpret \n.
> It canít rely on m// syntax to resolve it.

Its cant rely on the tokenizer to resolve it no. That is a general
rule, nearly.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"


perl.p5p at rjbs

Jun 4, 2012, 4:51 PM

Post #29 of 32 (139 views)
Permalink
Re: [perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

* Father Chrysostomos via RT <perlbug-followup [at] perl> [2012-06-02T08:29:07]
> > > The reason for it not being a bug is that, if m '\n' stops matching
> > > "\n", then $foo =~ $user_pat will stop working if the user enters '\n'.
> > >  That means ack '\n' won’t work any more.
> >
> > That doesnt make sense. Single quotes for ack are a shell quoting
> > issue. ack doesnt see the quotes.
>
> Either way, the regular expression engine itself has to interpret \n.
> It can’t rely on m// syntax to resolve it.

My understanding is that the regular expression engine has its own machinery
for turning \n into a \n to match, apart from the qq-ish behavior.

I could be wrong. Somebody tell me.

--
rjbs
Attachments: signature.asc (0.48 KB)


perlbug-followup at perl

Jun 4, 2012, 8:21 PM

Post #30 of 32 (140 views)
Permalink
[perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

On Mon Jun 04 16:52:26 2012, perl.p5p [at] rjbs wrote:
> * Father Chrysostomos via RT <perlbug-followup [at] perl> [2012-06-
> 02T08:29:07]
> > > > The reason for it not being a bug is that, if m '\n' stops
> matching
> > > > "\n", then $foo =~ $user_pat will stop working if the user
> enters '\n'.
> > > >  That means ack '\n' won’t work any more.
> > >
> > > That doesnt make sense. Single quotes for ack are a shell quoting
> > > issue. ack doesnt see the quotes.
> >
> > Either way, the regular expression engine itself has to interpret
> \n.
> > It can’t rely on m// syntax to resolve it.
>
> My understanding is that the regular expression engine has its own
> machinery
> for turning \n into a \n to match, apart from the qq-ish behavior.
>
> I could be wrong. Somebody tell me.

That’s right, which is why "\n" =~ '\n' matches, and why "\n" =~ m'\n'
should continue to match.

--

Father Chrysostomos


---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113094


demerphq at gmail

Jun 4, 2012, 11:04 PM

Post #31 of 32 (137 views)
Permalink
Re: [perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

On 5 June 2012 01:51, Ricardo Signes <perl.p5p [at] rjbs> wrote:
> * Father Chrysostomos via RT <perlbug-followup [at] perl> [2012-06-02T08:29:07]
>> > > The reason for it not being a bug is that, if m '\n' stops matching
>> > > "\n", then $foo =~ $user_pat will stop working if the user enters '\n'.
>> > > †That means ack '\n' wonít work any more.
>> >
>> > That doesnt make sense. Single quotes for ack are a shell quoting
>> > issue. ack doesnt see the quotes.
>>
>> Either way, the regular expression engine itself has to interpret \n.
>> It canít rely on m// syntax to resolve it.
>
> My understanding is that the regular expression engine has its own machinery
> for turning \n into a \n to match, apart from the qq-ish behavior.
>
> I could be wrong. †Somebody tell me.

I already said this was the case. The regex engine cannot depend on
the tokenizer handling *any* escapes, although there are some that are
handled by both the tokenizer AND the regex engine.

Tokenizer does nothing:

$ perl -Mre=debug -e'/\n/'
Compiling REx "\n"
Final program:
1: EXACT <\n> (3)
3: END (0)
anchored "%n" at 0 (checking anchored isall) minlen 1
Freeing REx: "\n"

Tokenizer does something:

$ perl -Mre=debug -e'my $x="\n"; /$x/'
Compiling REx "%n"
Final program:
1: EXACT <\n> (3)
3: END (0)
anchored "%n" at 0 (checking anchored isall) minlen 1
Freeing REx: "%n"

Notice the difference?

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"


rmbarker.cpan at btinternet

Jul 21, 2012, 10:41 AM

Post #32 of 32 (114 views)
Permalink
Re: [perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [In reply to]

On Sat, 2012-07-21 at 07:26 -0700, Tom Wyant via RT wrote:
> The ExtUtils-MakeMaker and DB warnings reported by Reini Urban are still
> present in 5.17.2. The former is also
> https://rt.cpan.org/Ticket/Display.html?id=77468

The latter is fixed by 7150f9197f27c7cc16a06b3e01391c49c78398ce

First page Previous page 1 2 Next page Last page  View All Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.