The new std.process is ready for review

[Lars T. Kyllingstad]

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"));


> 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.

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

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

Lars