On Mon, Nov 01, 2021 at 03:42:11PM +0700, Robert Elz wrote:
> ...
> 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).
Is this 'sole exception' in POSIX? It is what bash currently does.
Preferably the whole hash/remembering would be transparent,
only an implementation speedup.
Another case to think about:
# Having /usr/local/bin/ls executable
PATH=/usr/local/bin:/bin
hash -p /usr/local/bin/ls ls
ls # /usr/local/bin/ls
rm /usr/local/bin/ls
ls
How should the last 'ls' be handled?
Bash calls /bin/ls - which make the hash transparent. Good.
It might also have failed with '/usr/local/bin/ls: No such file or directory'.
> 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.
Good point!
> ps: should this be discussed for clarification in POSIX, I have no doubt
> which way the result would go.
There is the issue of 'command -p ...' changing the hash table.
Another issue is, the usage of hashed values
that are not based in the current PATH.
This could be seen as a root cause for the 'command -p ...' problem.
Not sure what the POSIX people would say about that.
--
Regards, Mike Jonkmans
