$proc.stdout is shorter than $proc.stdout.lines but most of the times is useless (trap)

[AlexDaniel]

See RT #132242. Basically, most users want .stdout.lines instead of .stdout, but for some reason it is not obvious. I've done this myself in the past.

[jnthn]

I've probably used Proc::Async as much as anyone, and a large number of times I actually was after the entire output, and whenever $p.stdout { $out ~= $_ } works totally fine for that case (and is potentially a lot more efficient than breaking it up into lines, if the thing writing the output uses output buffering). But yes, should document this clearly on the stdout/stderr methods that this is an asynchronous API, and will give you the data as it arrives, in the chunks it arrives in.

[AlexDaniel]

Huh. Yes, you were after the entire output, not chunks. This only tells me that we're maybe missing Supply.join. You can already do $p.stdout.reduce(*~*) but that's kinda meh.

In my naïve view of a perfect world, we could have had tapping on .stdout return an error message that suggested .lines, .join or .pass-thru, where .pass-thru would return the same supply but with the check disabled (so that you can tap on chunks if you really want to). This would make both .lines and .join behavior equally easy (or so), and will help people avoid the trap due to huffman coding. Ta-daa.