The new std.process is ready for review

[Steven Schveighoffer]

On Tue, 12 Mar 2013 17:18:43 -0400, Lars T. Kyllingstad  
<public at kyllingen.net> wrote:

> On Tuesday, 12 March 2013 at 14:10:34 UTC, Steven Schveighoffer wrote:
>> On Tue, 12 Mar 2013 03:31:30 -0400, Lars T. Kyllingstad  
>> <public at kyllingen.net> wrote:
>>>
>>> If you omit the AA parameter altogether, the child inherits the  
>>> parent's environment.  A null pointer is passed as 'envz' to  
>>> spawnProcessImpl(), which in turn passes this straight to  
>>> CreateProcess() on Windows and replaces it by 'environ' on POSIX.
>>>
>>> If you do specify the AA parameter, it is passed through toEnvz() on  
>>> its way to spawnProcessImpl().  If the AA is empty/null, toEnvz() will  
>>> create an empty (but non-null) environment block, and the child's  
>>> environment will be empty.
>>
>> I understand that point.  I am a little concerned, however, that  
>> passing null as env results in clearing the child environment.  These  
>> concerns are simply that the most common desire is to inherit the  
>> environment, and that there is no parameter that simply says "inherit  
>> parent environment," you have to call a different function.
>
> I'd be very interested to hear if you have a suggestion for a better way  
> to do it, keeping in mind that there needs to be *some* way to clear the  
> environment too.

Sadly, no I don't.  I had hoped [] would allocate an empty AA, but it  
fails to compile.

Note that you can "hack" it by setting a single environment variable which  
nobody will ever use.

i.e. spawnProcess("blah.exe", ["_____":"_____"]);

But that is really, really ugly.

>
>> I suppose it's no different than exec, which you have to call the right  
>> function depending on what you want.
>>
>> So this sounds fine.  The toEnvz still should be fixed to add an extra  
>> null, I'm assuming you're doing that right? :)
>
> Yes.  I have some local modifications based on the discussion here,  
> which I haven't pushed yet.  Waiting for you guys to finish debating the  
> file descriptor issue. ;)

I think all are in agreement at this point that closing the files between  
fork and exec is a good solution.  Whether or not to ALSO set F_CLOEXEC  
wherever Phobos opens a file descriptor is an additional matter.

As a fallback to standard unix behavior, we can have a Config option that  
says "don't do the close thing".

-Steve