"Jérôme M. Berger" wrote: > 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
While convenient, popen also invokes the shell to do it's bidding so you will get shell expansion and some performance penalty.
