Skip Menu |
Report information
Id: 126935
Status: resolved
Priority: 0/
Queue: perl6

Owner: cpan [at] zoffix.com
Requestors: zefram [at] fysh.org
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



From: Zefram <zefram [...] fysh.org>
Date: Tue, 15 Dec 2015 23:25:49 +0000
To: rakudobug [...] perl.org
Subject: [BUG] bad .perl for paths with pipe characters
Download (untitled) / with headers
text/plain 484b
The .perl method for IO::Path objects produces faulty output: Show quoted text
> "/foo|bar".IO.perl
q|/foo|bar|.IO(:SPEC(IO::Spec::Unix)) Show quoted text
> "/foo|bar".IO.perl.EVAL
===SORRY!=== Error while compiling /home/zefram/usr/lucifex/on_guile/EVAL_2 Two terms in a row at /home/zefram/usr/lucifex/on_guile/EVAL_2:1 ------> q|/foo|^bar|.IO(:SPEC(IO::Spec::Unix)) expecting any of: infix infix stopper statement end statement modifier statement modifier loop -zefram
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
To: "Zefram (via RT)" <perl6-bugs-followup [...] perl.org>
Date: Thu, 17 Dec 2015 12:22:56 +0100
Subject: Re: [perl #126935] [BUG] bad .perl for paths with pipe characters
Download (untitled) / with headers
text/plain 953b
Show quoted text
> On 16 Dec 2015, at 12:31, Zefram (via RT) <perl6-bugs-followup@perl.org> wrote: > > # New Ticket Created by Zefram > # Please include the string: [perl #126935] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=126935 > > > > The .perl method for IO::Path objects produces faulty output: >
>> "/foo|bar".IO.perl
> q|/foo|bar|.IO(:SPEC(IO::Spec::Unix))
>> "/foo|bar".IO.perl.EVAL
> ===SORRY!=== Error while compiling /home/zefram/usr/lucifex/on_guile/EVAL_2 > Two terms in a row > at /home/zefram/usr/lucifex/on_guile/EVAL_2:1 > ------> q|/foo|^bar|.IO(:SPEC(IO::Spec::Unix)) > expecting any of: > infix > infix stopper > statement end > statement modifier > statement modifier loop
$ 6 'say "/foo|\\bar".IO.perl.EVAL' "/foo|\bar".IO Fixed with 8d50dabfa9a3b690b18a , test added with e41c6617855b61678544f9 , can be closed. Liz
To: Elizabeth Mattijsen via RT <perl6-bugs-followup [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #126935] [BUG] bad .perl for paths with pipe characters
Date: Thu, 17 Dec 2015 15:16:33 +0000
Download (untitled) / with headers
text/plain 989b
Elizabeth Mattijsen via RT wrote: Show quoted text
>Fixed with 8d50dabfa9a3b690b18a
Done the hard way. Because it lacks most of the refinements of Str.perl, it looks like it might still have bugs that Str.perl avoids. For example, leading combining characters will become part of the grapheme of the opening delimiter, which won't match the closing delimiter if the matching is grapheme-aware. It is certainly LTA in its treatment of unprintables. You should (again?) consider calling .perl on the appropriate path attribute. The same method also has a similar escaping problem for $!CWD. Here the easy way doesn't just use a .perl call to escape the string; you can use .perl for the whole :$!CWD pair. You could profitably do likewise for the :$!SPEC pair, which doesn't have an escaping problem but does duplicate serialisation knowledge. I therefore suggest (untested) $.is-absolute ?? "{$.abspath.perl}.IO({:$!SPEC.perl})" !! "{$.path.perl}.IO({:$!SPEC.perl}, {:$!CWD.perl})" -zefram
To: Elizabeth Mattijsen via RT <perl6-bugs-followup [...] perl.org>
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [perl #126935] [BUG] bad .perl for paths with pipe characters
Date: Thu, 17 Dec 2015 17:09:33 +0100
Download (untitled) / with headers
text/plain 1.4k
Show quoted text
> On 17 Dec 2015, at 16:16, Zefram <zefram@fysh.org> wrote: > > Elizabeth Mattijsen via RT wrote:
>> Fixed with 8d50dabfa9a3b690b18a
> > Done the hard way. Because it lacks most of the refinements of > Str.perl, it looks like it might still have bugs that Str.perl avoids. > For example, leading combining characters will become part of the grapheme > of the opening delimiter, which won't match the closing delimiter if > the matching is grapheme-aware. It is certainly LTA in its treatment > of unprintables. You should (again?) consider calling .perl on the > appropriate path attribute. > > The same method also has a similar escaping problem for $!CWD. Here the > easy way doesn't just use a .perl call to escape the string; you can > use .perl for the whole :$!CWD pair. You could profitably do likewise > for the :$!SPEC pair, which doesn't have an escaping problem but does > duplicate serialisation knowledge. I therefore suggest (untested) > > $.is-absolute > ?? "{$.abspath.perl}.IO({:$!SPEC.perl})" > !! "{$.path.perl}.IO({:$!SPEC.perl}, {:$!CWD.perl})"
I see your point about escaping strings in a .perl. This has, however, much wider ramifications that will need to be checked. In any case, Str.perl cannot be used, because it puts double quotes around it. Which would be a set of double quotes too many. The points about $!SPEC.perlification knowledge living in 2 places and the fact that $!CWD wasn’t .perled, taken into account in 467582dbc9c621fe4bcf0fc363 . Liz
To: Elizabeth Mattijsen via RT <perl6-bugs-followup [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #126935] [BUG] bad .perl for paths with pipe characters
Date: Thu, 17 Dec 2015 16:31:48 +0000
Download (untitled) / with headers
text/plain 1.1k
Elizabeth Mattijsen via RT wrote: Show quoted text
>In any case, Str.perl cannot be used, because it puts double quotes >around it. Which would be a set of double quotes too many.
I think you've misunderstood somewhere. The code that I proposed does not have a multiple-quotation bug, but what you've committed *does*, for the CWD part. (I'm not sure what part of my suggestion you think gets this wrong. None of it introduces any delimiters itself.) For the main path attribute, calling .perl on the Str gets you one layer of quotation, which is exactly what you need. For CWD, calling .perl on the Pair object (as in my code) would again get you the needed single layer of quotation. What you've committed does ":CWD<{$!CWD.perl}>", which totals two layers of quotation. It gets one layer of quotation from .perl (on the Str value), and then surrounds that in a second layer of quotation consisting of the literal angle brackets. You could correct your code by changing the angle brackets to parens, following the arrangement you used for the SPEC part, ":SPEC({$!SPEC.perl})". You got quoting right once already (Str.perl). Stop trying to do the same job again! -zefram
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
To: Elizabeth Mattijsen via RT <perl6-bugs-followup [...] perl.org>
Date: Thu, 17 Dec 2015 18:24:16 +0100
Subject: Re: [perl #126935] [BUG] bad .perl for paths with pipe characters
Download (untitled) / with headers
text/plain 1.4k
Show quoted text
> On 17 Dec 2015, at 17:31, Zefram <zefram@fysh.org> wrote: > > Elizabeth Mattijsen via RT wrote:
>> In any case, Str.perl cannot be used, because it puts double quotes >> around it. Which would be a set of double quotes too many.
> > I think you've misunderstood somewhere. The code that I proposed does > not have a multiple-quotation bug, but what you've committed *does*, > for the CWD part. (I'm not sure what part of my suggestion you think > gets this wrong. None of it introduces any delimiters itself.) > > For the main path attribute, calling .perl on the Str gets you one layer > of quotation, which is exactly what you need. For CWD, calling .perl on > the Pair object (as in my code) would again get you the needed single > layer of quotation. What you've committed does ":CWD<{$!CWD.perl}>", > which totals two layers of quotation. It gets one layer of quotation > from .perl (on the Str value), and then surrounds that in a second > layer of quotation consisting of the literal angle brackets. You could > correct your code by changing the angle brackets to parens, following > the arrangement you used for the SPEC part, ":SPEC({$!SPEC.perl})”.
Indeed, it was a thinko, fixed in 12ba3410a13663b801c0 Show quoted text
> You got quoting right once already (Str.perl). Stop trying to do the > same job again!
Don’t think so: if you interpolate a Str into a “”, then it calls the .Str method on it, *not* the .perl method. So the path part of the .perl is not .perlified just yet. Looking into that now. Liz
To: Elizabeth Mattijsen via RT <perl6-bugs-followup [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #126935] [BUG] bad .perl for paths with pipe characters
Date: Thu, 17 Dec 2015 17:31:49 +0000
Download (untitled) / with headers
text/plain 669b
Elizabeth Mattijsen via RT wrote: Show quoted text
>Don't think so: if you interpolate a Str into a "", then it calls the >.Str method on it, *not* the .perl method.
I'm not sure where you think this is relevant. I was not expecting implicit .perl calls from any interpolation. The code that I proposed interpolates the results of explicit .perl calls. My reference to Str.perl was to say that that's the method that performs quoting correctly and therefore you should call it (directly or indirectly) when you require quoting. Indeed, with the Unicode behaviour being as complicated as it is, any ad hoc attempt to duplicate the quoting logic is bound to be incomplete. -zefram
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 167b
Looks like the mentioned have been fixed some time ago. Added another test for leading combiners for good measure, in https://github.com/perl6/roast/commit/1ed18b4319


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org