Return to Answer

The one Chris is referring to in his answer:

The one Chris is referring to in his answer:

An unset PATH is not to disable PATH lookup, but means using the system's default PATH which unfortunately on Debian, nobody agrees on (dash and bash have /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, zsh has /bin:/usr/bin:/usr/ucb:/usr/local/bin, ksh93 has /bin:/usr/bin, mksh has /usr/bin:/bin, execvp() (like in env) has :/bin:/usr/bin (yes, looks in the current directory first!)).

An unset PATH is not to disable PATH lookup, but means using the system's default PATH which unfortunately on Debian, nobody agrees on (dash and bash have /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, zsh has /bin:/usr/bin:/usr/ucb:/usr/local/bin, ksh93 has /bin:/usr/bin, mksh has /usr/bin:/bin ($(getconf PATH)), execvp() (like in env) has :/bin:/usr/bin (yes, looks in the current directory first!)).

Neither which nor type can know in advance that b/foo cannot be executed. Some shells like bash, ksh or yash, when invoking foo will indeed try to run b/foo and report an error, while others will run a/foo upon the failure of the execve() system call on b/foo.

Neither which nor type can know in advance that b/foo cannot be executed. Some shells like bash, ksh or yash, when invoking foo will indeed try to run b/foo and report an error, while others (like zsh, ash, csh, Bourne, tcsh) will run a/foo upon the failure of the execve() system call on b/foo.