[phobos] Major improvements to std.process

[Lars Tandle Kyllingstad]

I guess we should have the Windows functionality more or less in place 
before committing it to Phobos.  Besides, I don't have write access 
there yet.

If it's OK with you, I suggest we work out of my repo for the time 
being.  I don't mind giving you access to it.  Do you have a GitHub user 
account?

In the meantime I'll contact Andrei and arrange access to the Phobos SVN 
repository.

Btw, I've added the aforementioned convenience functions as well now, 
and I've version()ed out the things I believe to be POSIX specific. 
Also, check out the test_process.d file in the parent directory of ltk/, 
it contains a few tests that should also work on Windows.  (I had to put 
them in a separate file because of a failing Phobos unittest.)

-Lars


Steve Schveighoffer wrote:
> This all looks good.  Do you want me to access your repository to put in the necessary Windows stuff, or should we start putting this in phobos directly?
> 
> -Steve
> 
> 
> 
> ----- Original Message ----
>> From: Lars Tandle Kyllingstad <lars at kyllingen.net>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Fri, March 12, 2010 10:20:09 AM
>> Subject: Re: [phobos] Major improvements to std.process
>>
>> I've committed a new version with the following changes:
>> - Removed ChildTerminatedException, made wait() return -signal.
>> - Added GUI flag which does nothing on POSIX.
>>
>>
>> Steve Schveighoffer wrote:
>>> [...]
>>>
>>> It's just that the creation of the pipes and creation of the process always go 
>> hand in hand, you very seldom want to separate those functions.  It's somewhat 
>> of a nuisance to write many times "create this pipe, now this one, then create 
>> the process that uses them".  It would be much nicer to just say "create the 
>> process, use pipes for these handles, and give me everything back when you're 
>> done."  I liken it to how constructors unify the process of creation and 
>> initialization in one line.  Yes, you can split them, but why?
>>> I'm not saying there isn't use for your signatures, I agree having 
>> fine-grained control over which file descriptors are used is a good thing.  I 
>> just think we should cater to common cases, even if it's via wrapper 
>> functions/structs.
>>
>> Ok.  I agree there should be a set of convenience functions to take care of the 
>> most common tasks.  Here's a suggestion:
>>
>>   struct ProcessPipes
>>   {
>>       Pid pid;
>>       File stdin, stdout, stderr;
>>   }
>>
>>   // Spawn process with redirected input/output, return immediately.
>>   // Our version of popen().
>>   ProcessPipes pipeProcess(string command, RedirectFlags flags);
>>   ProcessPipes pipeShell(string command, RedirectFlags flags);
>>
>>   // Spawn process, optionally capture output, wait for it to finish,
>>   // return exit code.
>>   int execute(string command)
>>   int execute(string command, out string output);
>>
>>   // Run command in shell, optionally capture output, wait for
>>   // it to finish, return exit code.  (Already implemented.)
>>   int shell(string command);
>>   int shell(string command, out string output);
>>
>> -Lars