On 02/11/2026 11:35, Bruno Haible via Gnulib discussion list wrote:
Hi Collin,
In the find_in_given_path function, there are the following lines:
if (path == NULL)
/* If PATH is not set, the default search path is implementation
dependent.
In practice, it is treated like an empty PATH. */
path = "";
That isn't true on GNU/Linux, FreeBSD, and Solaris at least, where an
unset PATH searches the default path specified by
pathconf (_CS_PATH, ...) and an empty PATH searches the current working
directory.
Indeed, I confirm your finding, by running the attached program 'foo.c'
under 'strace -ff'.
So, I was mistaken about what an unset PATH environment variable means.
Perhaps the default to _CS_PATH I put here is better placed
in the Gnulib function? It has been in POSIX for a long time [1].
[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/confstr.html
Yes. Although the behaviour of find_in_given_path has been specified
for many years, I doubt that anyone would rely on this detail. It's
better to change it to follow POSIX's interpretation of a null PATH.
Done through the attached patches.
Nothing changes for platforms without confstr (native Windows, Android, Minix).
Bruno
I agree this change should be in gnulib.
I'm not sure about the fall back to empty path in gnulib though.
In the edge case where 256 is not enough we should IMHO:
errno=ENOMEM; return NULL;
We wouldn't want certain configs to fall back to
finding programs in the current directory.
cheers,
Padraig
