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