Re: hash not restored after running command -p

[Mike Jonkmans]

On Mon, Nov 01, 2021 at 09:09:19AM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 10:26 PM Mike Jonkmans <bashbug@jonkmans.nl> wrote:
> > POSIX is also silent on this.
> 
> I think ``Once a utility has been searched for and found [...], an
> implementation may remember its location and need not search for the
> utility again unless the PATH variable has been the subject of an
> assignment'' pretty much covers it.

This wording does not cover it wholly, in my opinion.
Because when the utility's hashed path is not in $PATH,
then the utility should not have been searched for at all.
It should not be found, even if it is remembered.

The way it works now, is that the hashed keys are made into aliases.
These hash-aliases circumvent PATH search.
It is not specified by POSIX and I think it is an unwanted trap.

> `command -p command_name' doesn't
> alter `PATH', and the shell may or may not remember the location of
> `command_name' obtained using the default value for `PATH'.

Implicitly this sets PATH.
So it should not mess with the outcome of later PATH searches.

> > Note that it is not always the same person writing the code.
> > The script might be written/changed by someone unaware of the side effects.
> > I assume script writers would know about PATH and alias effects,
> > less so about 'hash' and even fewer people would know about 'command -p'.
> 
> Yeah, it'd be better if the feature in question were documented.

Best would be to only return hash matches that are in PATH.
Second best would be to let 'command -p' not mess with the hash.
Third best is document current behaviour.

--
Regards, Mike Jonkmans