On 05/26/2010 08:59 AM, Eric Blake wrote:
Several systems now offer execvpe(); it wouldn't be that hard to
add a
gnulib wrapper function that guarantees it everywhere.
>
> It doesn't hugely matter which semantics we have - which do you
> suggest.
I haven't exhaustively tested, but env(1) (which is as close as you can
get to a standardized execvpe(2)) honors the PATH of the parent, not of
the child's new environment. If I were to implement execvpe() in
gnulib, I would document it that way, as well.
Scratch that. POSIX gives this example:
http://www.opengroup.org/onlinepubs/9699919799/utilities/env.html
The following command:
env -i PATH=/mybin:"$PATH" $(getconf V7_ENV) mygrep xyz myfile
invokes the command mygrep with a new PATH value as the only entry
in its environment other than any variables required by the
implementation for conformance. In this case, PATH is used to locate
mygrep, which is expected to reside in /mybin.
In other words, POSIX suggests that execvpe(), if it exists, should
honor the PATH after modifications from the new env[], rather than from
the parent.
Hmm - that makes me wonder if POSIXLY_CORRECT should be included in the
list of environment variables passed during virCommandAddEnvPassCommon -
or for that matter, all env-vars listed by $(getconf V7_ENV) for the
given system.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org