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@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