On Fri, 18 Aug 2017 08:35:18 -0700, alex.jakime...@gmail.com wrote:
> Most command line tools support zero-separated input and output (grep
> -z, find -print0, perl -0, sort -z, xargs -0, sed -z).
>
> And while you can use .stdout.lines to work on things line-by-line,
> doing the same thing with null-byte separators is significantly
> harder.
>
> <jnthn> Anyway, it's pretty easy to write yourself
> <jnthn> Something like
> <jnthn> supply { my $buffer = ''; whenever $stdout { $buffer ~= $_;
> while $buffer.index("\0") -> $idx { emit $buffer.substr(0, $idx);
> $buffer .= substr($idx + 1); } LAST emit $buffer } }
>
> I agree that it is not too hard, but it should be built in.
>
> One could argue that it should be *easier* to do this than to work on
> stuff line-by-line. People usually don't expect newlines in filenames,
> but it is legal and therefore any code that expects non-null separated
> paths is broken. Not sure if we should go so far in trying to get the
> huffman coding right, but a built-in way to work with data like this
> would be a great step.
That'd only work for strings, while .split can also split on regexes. I'd say
we defer this until Cat (lazy strings) is implemented and then do the
full-featured .split and .comb on it.
The exact same issue exists in IO::Handle, which currently implements it by
slurping the entire file first.
