On Sat, 23 Feb 2013 11:42:26 -0500, H. S. Teoh <hst...@quickfur.ath.cx>
wrote:
- wait():
- Some code examples would be nice.
- For the POSIX-specific version, I thought the Posix standard
specifies that the actual return code / signal number should be
extracted by means of system-specific macros (in C anyway)?
Wouldn't it be better to encapsulate this in a POD struct or
something instead of exposing the implementation-specific values to
the user?
We handle the extraction as an implementation detail, the result should be
cross-platform (at least on signal-using platforms). I don't know what a
POD struct would get you, maybe you could elaborate what you mean?
- How do I wait for *any* child process to terminate, not just a
specific Pid?
I don't think we have a method to do that. It would be complex,
especially if posix wait() returned a pid that we are not handling!
I suppose what you could do is call posix wait (I have a feeling we may
need to change our global wait function, or eliminate it), and then map
the result back to a Pid you are tracking.
You have any ideas how this could be implemented? I'd prefer not to keep
a global cache of child process objects...
- execute() and shell(): I'm a bit concerned about returning the
*entire* output of a process as a string. What if the output generates
too much output to store in a string? Would it be better to return a
range instead (either a range of chars or range of lines maybe)? Or is
this what pipeProcess was intended for? In any case, would it make
sense to specify some kind of upper limit to the size of the output so
that the program won't be vulnerable to bad subprocess behaviour
(generate infinite output, etc.)?
Yes, pipeProcess gives you File objects for each of the streams for those
cases where you expect lots of data to be returned, or want to process it
as it comes. This is the use case I expect most people will use.
There is no doubt good use cases for execute/shell, we have a lot of
non-generic string processing functions in phobos, and a lot of command
line tools on an OS produce a concise output that can be used.
In general, for input streams, ranges are not a good interface. Output
ranges are good for output though, and I think File is a valid output
range.
- ProcessException: are there any specific methods to help user code
extract information about the error? Or is the user expected to check
errno himself (on Posix; or whatever it is on Windows)?
This is a good idea. Right now, ProcessException converts the errno to a
string message, but we could easily store the errno.
I say we, but I really mean Lars, he has done almost all the work :)
-Steve
