The new std.process is ready for review

[Vladimir Panteleev]

On Wednesday, 6 March 2013 at 07:27:19 UTC, Lars T. Kyllingstad 
wrote:
> In principle, I like that idea.  In fact, you'll see that 
> execute() and shell() are now both implemented using a function 
> similar to (and inspired by) the collectOutput() method you 
> suggested.  Furthermore, pipeProcess() and pipeShell() both 
> forward to a pipeProcessImpl() function which takes a spawn 
> function as a template parameter.

OK, this sounds reasonable. It's just that it's easy to get a 
little overwhelmed by the number of various functions at first, 
and we've seen some confusion regarding them already. Could we 
add a 2-by-3 table at the top of the module, to visualize how the 
various function flavors relate to each other?

> Now, the output and error streams are redirected into separate 
> pipes.  But what if "foo" starts off by writing 1 MB of data to 
> its error stream?

What's the problem here? If the goal is to collect both stdout 
and stderr, and the problem is pipe clogging, we should try to 
solve that. In fact, if we do come up with a correct 
collectOutput implementation, it would likely be useful to make 
the function public. It would be especially useful if the 
function could also correctly feed the subprocess input from a 
buffer (string), which could be passed as an optional parameter 
to collectOutput.

> Maybe I'll just have to bite the bullet and accept a different 
> name. :(  It really seems to be the one thing that is 
> preventing the two modules from being combined.  Suggestions, 
> anyone?

runShell? executeShell?