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
<[email protected]> 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
