Re: [libvirt] [PATCH 0/3 RFC] Demonstrating a new API for spawning processes
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)