[phobos] Suggestions for std.process

[Steve Schveighoffer]

----- Original Message ----
> From: Lars Tandle Kyllingstad <lars at kyllingen.net>
> 
> Steve Schveighoffer wrote:
> > Some things about my experience with Tango's Process:
> > 
> > 1. I included a similar "redirect flags" option for the process, with the 
> added ability to redirect stdout to stderr and vice versa.
> 
> That's a good idea.
> 
> I've actually considered making it even more general, by allowing the user to 
> provide File objects to replace the standard streams.  This would make it easy 
> to use the output from one process as input to another, or to pass the contents 
> of a file to a process' input stream. A simplified example that emulates "foo | 
> bar":
> 
>   Pid spawnProcess(string executable, File useThisAsInput);
> 
>   // foo | bar
>   auto fooPid = spawnProcess("foo");
>   auto barPid = spawnProcess("bar", foo.stdout);
> 
>   // baz < myfile.txt
>   auto bazPid = spawnProcess("baz", File("myfile.txt");
> 
> What do you think?

That sounds like a good idea.  Hm... I read the std.stream code, and I wasn't aware that Phobos used its own buffering layer in place of C's for everything but the standard handles.  That is good news!  However, you are still using FILE * in your code, you should get rid of that (I don't even know where the File.wrapFile function is).

> > 2. About the searchPath flag -- Windows' function to create a process already 
> takes into account the PATH variable, so I'm guessing that flag will be a noop 
> on Windows?  Also, execlp and execvp already take into account the PATH.  I 
> can't imagine you would need to build your own PATH parsing/searching method, or 
> to run a command without taking the PATH into account (you can do this anyways 
> by prepending a './').  My advice is to simply use one of those versions of 
> exec, and get rid of the searchPath flag.
> 
> I really can't decide what I think is best.  On one hand, having the function 
> always search the path is convenient, on the other hand, if your program is 
> going to execute another, there should be as little chance as possible of it 
> executing the wrong program.  (The latter may be of small concern, though, since 
> one can just include a directory in the executable name.)
> 
> Importantly, though, I think code in Phobos should work in the same way on both 
> Windows and POSIX, so that more or less settles it for me.
> 
> The main reason I wrote my own path-searching mechanism is that the execvp 
> function not only searches the path, but if that fails it also tries to run the 
> command through the shell.  For some reason I find that annoying.

Hm... that is annoying.  Now that I look at Tango, it actually uses execve, and does the path parsing (only on Linux/Mac/BSD however).  As you say, it should work the same on both Windows and POSIX, so I think that path search should be implicit.

> > 3. Tango's Process object included a means to specify the environment for the 
> child process (a useful feature).  A simple argument with a string[string] for 
> the environment variables would be useful.
> 
> That's coming soon, just haven't gotten around to it yet. :)  In fact I have a 
> few ideas regarding environment variables.  The getenv() function has no 
> business being in std.process.  Rather, the following functions should be in 
> std.system:
> 
>   string getEnv(string varName);
>   string[string] getEnv();

Sounds good.

> > 5. Some version that parses a command line would be useful.  For example, it 
> would be nice to be able to simply do spawn("ls -l");
> 
> (That being the default on Windows, right?)  I have considered a spawnShell() 
> function, would that be anything like what you're suggesting?

What I mean is, having a method that parses the command line according to simple sane rules and calls the array-style version.  I don't suggest simply passing the command to Windows, as the parsing and quote escaping is so ridiculous, nobody should have to deal with it.  Wait until you see it :)

> > 7. Windows has an additional flag to specify that no console should be 
> created.  This is very essential for things like plugins (where you don't want a 
> black console box to pop up while running a child process).  The way I handled 
> this in Tango is to add a gui flag which was a noop in Linux.
> 
> My biggest problem here, which I mentioned in my first e-mail, is that I have no 
> experience whatsoever with the Windows API.  I don't even have a computer with 
> Windows on it.  (Though I may be able to get a Windows licence through work, 
> I'll have to check that out.  Then I'll set up a virtual machine or something.)
> 
> In the event that I'm able to get Windows, we are left with three options, 
> either of which is fine by me:
> 
> 1. I spend some time on it, and write it myself, from scratch.  This will take a 
> while.
> 
> 2. You, as the author of Tango's Process class, if possible, give me permission 
> to take the Windows part of that code and adapt it to Phobos.  So far I haven't 
> looked at it, due to those dreaded licensing issues.
> 
> 3. Someone else writes the Windows version.  This is the fastest option by far, 
> but I guess manpower is in short demand.
> 

As long as we agree on the interface, I can write the Windows version.  I am not the original author of Tango's Process class, that was Reagan Heath, and then Juan Comellas.  I took over because I needed some functionality that wasn't there, and I found some bugs, and Juan had stopped maintaining it.  Therefore, I can't really give you full permission to copy Tango's Process class.

But I did write the Windows quote parsing part of it, so I have no problems copying that over.  The rest is pretty straightforward code that can easily be rewritten from scratch.

-Steve