Running external program from a D program [D2]

[Lutger]

"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.