[phobos] Suggestions for std.process

[Lars Tandle Kyllingstad]

Steve Schveighoffer wrote:
> 
> 
> 
> ----- 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.

That sounds like a great plan, and will most likely by far be the 
fastest way to get it up and running on both systems.  I'll keep working 
on the POSIX stuff, implementing and fixing the things we have 
discussed, and try to work the interface into something we can all agree 
is good.

I would also like some feedback on how well you guys think the interface 
will fit with the new concurrency model.  The idea was, as I said 
before, to write it in the same style, and when the time comes it should 
  (API-wise) be a simple, non-breaking change to just add a MessageBox 
to the Pid struct.

-Lars

-- 
Lars Tandle Kyllingstad
@: lars at kyllingen.net
#: 40233221
w: http://www.kyllingen.net