On Fri, Sep 12, 2014 at 6:24 PM, Eric Blake <ebl...@redhat.com> wrote: > On 09/12/2014 02:15 PM, Christian Franke wrote: >>>> unsetenv("PATH"); >>> This is undefined behavior, per POSIX. POSIX recommends that you always >>> leave PATH defined to at least a bare minimum of the results of >>> confstr(_CS_PATH, ...); it also states that implementations are free to >>> do what they want (in this case, crash) if you don't follow the >>> recommendation: >>> >>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html >>> "If PATH is unset or is set to null, the path search is >>> implementation-defined." >> >> There is no POSIX PATH search needed in my testcase: >> execl("/usr/sbin/alternatives", ...) > > PATH may not be needed for execl() to find the binary it will be > executing, but it IS required to be set in the environment to the bare > minimum of confstr(_CS_PATH) for that binary to have a chance of > executing in a well-defined setup.
Eric, I think your interpretation is wrong. The line you quote from POSIX refers to a "path search" but there is no path search happening here. The concept of path search is implicitly defined by the first line in your citation: "PATH: This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename." Notice the way this sentence ends. The argument to execl() is a full path, not "only a filename", thus no PATH search is involved. I agree that unsetting PATH is not ideal practice but I think it's perfectly well defined by POSIX. David -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple