Re: hash not restored after running command -p

[Robert Elz]

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.