Review request for 5049299
martinrb at google.com
Tue Jun 9 11:42:04 PDT 2009
On Tue, Jun 9, 2009 at 09:28, Michael McMahon <Michael.McMahon at sun.com>wrote:
> Martin Buchholz wrote:
>> In the old implementation, we used the strategy of
>> fork+mutate environ+execvp
>> and we got the traditional shell script semantics
>> from our use of execvp.
>> Since environ is now a global shared-with-parent variable,
>> we can't mutate it any more, therefore can't use execvp,
>> and must implement the missing execvpe ourselves.
One more note: we could try to have two implementations of
execvpe, one that mutated environ and one that didn't,
since each has its own advantages,
but I think that would be even harder to understand and maintain.
Looking at the code again, it seems like it would not be too much work.
Here's an untested example of how we could do both.
execve_with_shell_fallback(const char *file,
const char *argv,
const char *const envp)
execve(file, (char **) argv, (char **) envp);
if (errno == ENOEXEC)
execve_as_traditional_shell_script(file, argv, envp);
extern char **environ;
environ = (char **) envp;
execvp(file, (char **) argv);
What do you think?
>> Now, strictly speaking, execvp's traditional shell script semantics
>> is an unspecified implementation detail of execvp;
>> on other Unix platforms we might not need this. We can leave this to, e.g.
>> the BSD porters reading this,
>> to add some #ifdefs.
>> Ok, got you.
>> (It would also be good if you ran the updated tests on
>> Solaris with the old implementation to confirm my understanding)
> I'm just building it now, and will run the test then.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev