On Thu, 02 Mar 2017 02:29:27 -0800, zef...@fysh.org wrote:
> > spurt("foo\x[0]bar", "wibble")
> True
>
> The above writes to a file named "foo". It is less than awesome that
> Perl 6 accepts "foo\x[0]bar" as a pathname, when it doesn't resemble
> any pathname valid on the OS, and silently treats it as a quite
> different pathname. It would be better for it to signal an error, that
> "foo\x[0]bar" isn't a pathname. It's not an outright bug that it aliases
> pathnames in this manner, but it is liable to confuse other code that
> manipulates pathnames. Code like this:
>
> > $*SPEC.splitpath("foo/bar\x[0]baz/quux").perl
> ("", "foo/bar\0baz/", "quux")
>
> This *is* an outright bug. If the string containing a nul is to be
> accepted as a way of stating a pathname, as it is by spurt(), then
> IO::Spec needs to know about that rule, and needs to parse pathnames
> accordingly. The above should behave the same as splitting "foo/bar",
> and thus should return ("", "foo/", "bar"). It could optionally retain
> the nul and everything following it as part of the basename component
> of the output, but though technically correct that would be confusing.
> Of course, if spurt() et al did not accept nuls in pathnames, then
> splitpath ought to error on such inputs too.
>
> Watch out for "\x[0]\x[308]" when trying to detect nuls.
>
> -zefram
Thank you for the report. This is now fixed in high-level IO routines and
clases:
Fix: https://github.com/rakudo/rakudo/commit/e6814986c0
Tests: https://github.com/perl6/roast/commit/b16fbd3b24
For the case of $*SPEC.splitpath: it's a low-level routine that most users won't
be using, unless they're developing their own path manipulation routines. So, in
that case, I'm leaving them without any nul detection, documenting the fact that
it needs to be done by the users of these low-level routines in:
https://github.com/perl6/doc/commit/d436f3cc7896799f3358f99321b40b3b5512a72b
- IO grant
