Calling external programs from D

[pragma]

In article <e1g3sr$212p$1 at digitaldaemon.com>, Lionello Lunesu says...
>
>Just some idea:
>
>Wouldn't it be nice if there were an "extern (System)" calling 
>convention that would start external programs?
>
>For example:
>
>#extern (System) int wget(...);
>#
>#int main() {
>#  return wget("http://whatever");
>#}
>
>This would boost productivity especially for D scripts. Only too often I 
>need a small, temporary program to process some data and I wish I had 
>the compilable source of wget/grep/utility-x at hand to incorporate 
>their functionality.

Nice idea.  The (System) convention is really just a macro to wrap a call to
std.system() right?

If it helps, I recently came up with a solution to handle cross-platform
scripting using D.  It handles all the differences between Linux and Windows
shells, including handling forward and backward slash conventions.

'Script' Library:
http://www.dsource.org/projects/ddl/browser/trunk/utils/Script.d

Example Script:
http://www.dsource.org/projects/ddl/browser/trunk/buildutils.d

The symbols from Script are imported using a template so the script can be run
with a very minimal command line (a techinique that sadly only works under
Windows), provided the utils/ directory is in scope.  Otherwise, the developer
has the option of compiling it into an .exe.


>Seems easy enough to implement using spawning/waiting. The program can 
>be declared with "..." or some defined arugments, but all arguments to 
>the function would have to be cast to char[] for passing to the new 
>process. Would of course be even cooler if the linker could pull in the 
>external program's main(), but I suppose that's a bit tricky :)

This is actually quite tricky to do - pull this off and you're half-way to
writing your own shell.  Using System() is probably more efficent in terms of
overhead and RAM/CPU usage.  Plus, you don't have to worry about trying to
emulate shell features like the current $path and command aliases.

- EricAnderton at yahoo