The new std.process is ready for review

[Steven Schveighoffer]

On Thu, 14 Mar 2013 17:51:36 -0400, Lars T. Kyllingstad  
<public at kyllingen.net> wrote:

> On Thursday, 14 March 2013 at 20:34:11 UTC, Steven Schveighoffer wrote:
>> On Thu, 14 Mar 2013 16:20:24 -0400, Lars T. Kyllingstad  
>> <public at kyllingen.net> wrote:
>>
>>> The more I think about this, the more it seems like a good idea:
>>>
>>> [...]
>>>
>>> Looks good?
>>
>> Looks good.
>>
>> Part of me thinks you shouldn't have to specify environment in order to  
>> specify redirects, but I don't know how that works with the overloads.   
>> I know File is a struct, so it shouldn't bind to null, right?
>
> No, there won't be any problem with adding overloads with and without  
> environment, but then there'll be six spawnProcess() versions.  We have  
> to weigh that against the user having to explicitly specify a null when  
> they don't want to add to the environment, but still want redirects.  I  
> don't know which is worse.  I don't think this is too bad, though:
>
>    auto p = spawnProcess("myapp", null, File("input.txt"));

OK, that is fine with me.

>> By "AA should be merged with the parent's environment or not, with the  
>> former being the default", I'm assuming the "set" flag will mean "don't  
>> inherit".  What name do you have in mind?  Since we already have  
>> dontDoTheCloseThing, I think dontDoTheEnvironmentInheritThing would be  
>> good ;)
>>
>> I know it's bikeshedding, but negative flags are awful, we should come  
>> up with positive ones.  ignoreParentEnv?
>
> Now that the big pieces are seemingly falling into place, it is probably  
> time for bikeshedding.  I was thinking clearEnv or newEnv, but  
> ignoreParentEnv is perhaps more explicit.

clearEnv is somewhat incorrect, since you could specify a new environment  
via the env parameter, it won't be clear.
newEnv sounds ok, and probably is better than ignoreParentEnv to avoid a  
more verbose name, even if less descriptive.  At the very least, it will  
make people look it up ;)

>
> Speaking of negative flags, do you have better suggestions for the  
> Config.noCloseStd... ones?

retainStdout

> dontDoTheCloseThing became inheritFDs, btw. :)  Also open for  
> suggestions on that one.

That is fine with me.

-Steve