Re: Possible bug: HASH_CMDS has no observable effect

[Phil Pennock <zsh-workers+phil.pennock@spodhuis.org>]

On 2020-09-11 at 17:01 +0200, Roman Perepelitsa wrote:
> Could you clarify how this statement is related to my bug report?

Sure thing.  You quoted documentation which also covered a combination
not in effect, reported Zsh's behavior, and wrote:

} I took this to mean that after installing rsync and invoking it,
} ${commands[rsync]} will be set and running `hash` will display an
} entry for rsync. This, however, is not the case.

I explained the observed behavior, relative to the quoted documentation,
and what was going on.

> In case this wasn't clear, in my bug report the output of the
> following two commands is not what I expect:
> 
>   # print $+commands[rsync]
>   0
>   # hash | grep rsync
>   #
> 
> The expected output:
> 
>   # print $+commands[rsync]
>   1
>   # hash | grep rsync
>   rsync=/usr/bin/rsync
>   #
> 
> The reason why I expect this output is because I've invoked rsync
> right before these two commands while HASH_CMDS was in effect.

There's two issues here, and it does look to me like the docs are out of
date.

Per the documentation, the first time you invoked `rsync`, an entry was
added to the cache and thereafter when you invoked rsync, the cached
entry was used.  So the quoted examples don't make the documentation
wrong.

Except that's not what's going on, because even if rsync is installed
before you first try to run it, the same thing happens.  So it looks
like zsh is preemptively building the command hash and not remembering
when you do first run it.

If you install rsync before first trying to access it, the docs imply
that it should just work for you.  Instead, you need to `rehash` first.


Can anyone speak to whether we should change the documentation or the
behavior?  If the documentation, can someone who's not a maintainer
suggest text which is sufficiently clear to them?

-Phil