> On 17 Dec 2015, at 16:16, Zefram <zef...@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
