Re: Possible bug: HASH_CMDS has no observable effect

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sun, Sep 13, 2020 at 2:31 AM Roman Perepelitsa
<roman.perepelitsa@xxxxxxxxx> wrote:
>
> This is what I expected to happen but that's not what actually
> happens. Sometimes, when HASH_CMDS is set, a successfully invoked
> command does not get hashed.

Ah ... recall that several messages back, I wrote:
> A complication of this is that the completion system also invokes
> command hashing in order to be able to use the $commands associative
> array.  So if you use completion at all, you might also find that
> command (re)hashing works differently than in a "zsh -f" shell.

I forgot that even with zsh -f, interactive shells load the
zsh/compctl and zsh/complete modules.

Those are causing the $commands hash to be immediately repopulated as
soon as $path is changed, and HASH_DIRS is also set by default, so
further updates to the hash table do not occur.  If you were to create
/tmp/foo/bar before adding /tmp/foo to the path, you would see what
you expect.

It appears that throughout this thread I've been conflating the
command being "not found" by correction [spckword()] with the command
being "not found" by execute().  Sorry about that.