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

[Eric Blake]

On 05/26/2010 08:44 AM, Daniel P. Berrange wrote:
>> The $PATH of the parent process, or the $PATH of the environment passed
>> to the child process?  That can make a subtle difference, if one uses
>> virCommandAddEnvString(cmd, "PATH=...").
> 
> I was going to say 'the same rules as execvp' but I now realize there
> is no execvp variant that also accepts a  char * argv + char *env[]. 
> Only a va_args variant. And execve doesn't do path resolution.

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.

>> If the same env-var is added more than once, are we guaranteeing that
>> the last one wins?  In other words, it should be easy to call
>> virCommandAddEnvPassCommon(cmd) && virCommandAddEnvString(cmd,
>> "PATH=...") to override just PATH.
> 
> What does execve() do if env[] has the same name twice ? We'll just
> be delegating to that 

POSIX leaves it unspecified which entry is found if env[] lists the same
value more than once.  Some implementations favor the first, while
others favor the last.  Semantically, I'd rather guarantee that we favor
the last (it makes the virCommand* API easier to use), but to do that,
it means we have to manually search all prior env entries for duplicates.

> 
>> Should there be an easy way to specify that a particular child process
>> should keep the localization settings of the parent, rather than the
>> LC_ALL=C of virCommandAddEnvPassCommon?
> 
> AFAIK, none of our current usage requires it, but if the conversion
> of existing code requires it, we can adapt.

No rush, then - wait until we have a use case (if ever).

-- 
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/f726918f/attachment-0001.sig>