Jonathan M Davis wrote: > Jesse Phillips wrote: >> As you may have noticed by the comments to on bug 3158. exec()[1] calls >> replace your process, this means it will not continue your program. To >> get arround this you find that people will first fork()[2] and exec on >> the child process. > > Ah yes. Threads are all part of the same process, so you have to fork rather > than create a new thread. Whoops. I should have thought of that. But I guess > that comes from my almost never using fork and even only using threads when > I have to. Of course, it would be nice if there were a function in phobos to > abstract that out, but there's enough work to do on phobos that that's > probably not at the top of the list by any means. > >> In order to get your standard output you would use the dup2()[3] call. >> >> Please note that I do not know how any of this will related to practices >> on Windows. And sadly this is not D specific and actually C stuff. >> >> 1. http://www.opengroup.org/onlinepubs/007908799/xsh/exec.html >> 2. http://www.yolinux.com/TUTORIALS/ForkExecProcesses.html >> 3. http://www.mkssoftware.com/docs/man3/dup2.3.asp > > Well, it's good info. So, thanks. But it would be nice if that too were > nicely abstracted in phobos. The undocumented shell() command works, but it > uses the shell, so you have to worry about escaping characters. Bleh. In any > case, thanks for the info. > In C, you have popen which allows to start a child process and capture either the standard input or the standard output. It is originally a POSIX function, but AFAIK it exists also on Windows (although it might be called _popen there).
Jerome
--
mailto:[email protected]
http://jeberger.free.fr
Jabber: [email protected]
signature.asc
Description: OpenPGP digital signature
