bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hash not restored after running command -p


From: Mike Jonkmans
Subject: Re: hash not restored after running command -p
Date: Mon, 1 Nov 2021 15:41:33 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]