demerphq at gmail
Jun 2, 2012, 5:45 AM
Post #28 of 32
(71 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/"
|
signature.asc
