> Sounds like a bug in GNU's ld.so more than anything. It's neither unique to glibc (AIX, Solaris) nor to LD_LIBRARY_PATH (PATH), nor trailing colons (leading

> Sounds like a bug in GNU's ld.so more than anything. It's neither unique to glibc (AIX, Solaris) nor to LD_LIBRARY_PATH (PATH), nor trailing colons (leading colons, adjacent colons). This de facto standard becomes a little more obvious when one considers a likely implementation (iterating over "strchr(arg, ':')" or whatever). Any of these sequences then will give up an empty string: PATH=:/foo PATH=/foo: PATH=/foo::/bar And an empty string is equivalent to dot for chdir(2). zwp:/tmp$ cd '' zwp:/tmp$ pwd /tmp zwp:/tmp$ (This is not the same as plain "cd" (ie with no args), which is a special case that takes you $HOME, of course). I agree it's surprising and potentially dangerous. FWIW, the execp() functions hide a similar wtf. From the Linux man page: The file is sought in the colon-separated list of directory pathnames specified in the PATH envi‐ ronment variable. If this variable isn't defined, the path list defaults to the current directory followed by the list of directories returned by confstr(_CS_PATH). Security conscious programs that clear the environment and then call eg execlp() end up searching dot before the system path. Yay.