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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list