(original) (raw)

On Tue, Jun 9, 2009 at 09:28, Michael McMahon <Michael.McMahon@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.

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

static void
execve\_with\_shell\_fallback(const char \*file,
�� const char \*argv\[\],
�� const char \*const envp\[\])
{
#if USE\_CLONE
�� execve(file, (char \*\*) argv, (char \*\*) envp);
�� if (errno == ENOEXEC)
�� execve\_as\_traditional\_shell\_script(file, argv, envp);
#else
�� extern char \*\*environ;
�� environ = (char \*\*) envp;
�� execvp(file, (char \*\*) argv);
#endif
}

What do you think?

Martin
�

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.

Thanks,
Michael.