I agree, this looks to be broken in bash - "command -p cmd" is (logically)
oldpath=$PATH PATH=/standard:/system:/path cmd PATH=$oldpath and should act (as if) that way. What's more, from all the shells I have tested, bash is the only one to behave like this, every other shell (including zsh), when set up so that "ls" is not found in PATH (typically by removing /bin from PATH - perhaps different on some systems, or with more removed - and regardless of whatever else is left there) does ksh93{2} $ ls /usr/pkg/bin/ksh93: ls: not found [No such file or directory] ksh93{2} $ command -p ls; ls [list of files in "." from "command -p ls" deleted here] /usr/pkg/bin/ksh93: ls: not found [No such file or directory] ksh93{2} $ which is how it should be - the hash table is intended to speed PATH searches for commonly used commands, nothing should be found there which wouldn't be found from a PATH search - with the sole exception that the shell isn't required to check that the filesystem hasn't changed out from under it (eg: putting a new "ls" in some directory mentioned in PATH before /bin - if that happens, the user needs to inform the shell, using "hash -r" (or possibly, an assignment to PATH). This is also somewhat inconsistent in bash, if one does, with the same setup as above, but without having done the "command -p ls", then: PATH=/bin ls the ls command works, "ls" is found by the PATH search, but is not added to the hash table (which is correct). A subsequent "ls" correctly says: bash: ls: command not found If it is to be considered correct to add the entry in the command -p case, why would it not be correct in this case as well? The only difference is where the (temporary) modified PATH comes from. kre ps: should this be discussed for clarification in POSIX, I have no doubt which way the result would go.