Mailing List Archive

1 2  View All
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@perl.org> wrote:
> On Fri Jun 01 17:57:55 2012, sprout wrote:
>> On Fri Jun 01 14:40:56 2012, public@khwilliamson.com 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/"
[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@perl.org> wrote:
> > On Fri Jun 01 17:57:55 2012, sprout wrote:
> >> On Fri Jun 01 14:40:56 2012, public@khwilliamson.com 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
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@perl.org> wrote:
> On Sat Jun 02 02:07:11 2012, demerphq wrote:
>> On 2 June 2012 03:01, Father Chrysostomos via RT
>> <perlbug-followup@perl.org> wrote:
>> > On Fri Jun 01 17:57:55 2012, sprout wrote:
>> >> On Fri Jun 01 14:40:56 2012, public@khwilliamson.com 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/"
Re: [perl #113094] Keeping track of 'Unescaped left brace in regex is deprecated' [ In reply to ]
* Father Chrysostomos via RT <perlbug-followup@perl.org> [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
[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@rjbs.manxome.org wrote:
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [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
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@rjbs.manxome.org> wrote:
> * Father Chrysostomos via RT <perlbug-followup@perl.org> [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/"
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

1 2  View All