[libvirt] [PATCH 0/3 RFC] Demonstrating a new API for spawning processes

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100526/2e28196a/attachment-0001.sig>