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?
