Re: Possible bug: HASH_CMDS has no observable effect

[Bart Schaefer <schaefer@brasslantern.com>]

On Sat, Sep 12, 2020 at 12:02 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> Do I understand it correctly that this is working as intended? It
> appears to contradict the documentation for HASH_CMDS, which states
> that commands are hashed when they are invoked for the first time.

What it really means is that commands are hashed the first time a path
search finds them.

If you have only HASH_CMDS, then "a path search finds" just the single
command you invoked.  If you tend to be using one, or a few, commands
repeatedly, and never invoke anything else, this is all you need to
avoid path search overhead for commands that exist.  It remains
"expensive" to discover that a command does not exist.

If you also have HASH_DIRS set, then "a path search finds" every entry
in every directory that is searched.  This eliminates the search
overhead for any external command you might use in the future.  In
order to avoid the expense of a useless search when for example you
make a typo, the assumption is made that if the command is not already
in the cache then it must not be in any part of the path that has
previously been searched.  The whole search-and-cache process is
short-circuited.

This really is the intended behavior, because for most people most of
the time new commands do not appear in the path during a shell
session.  It's also the reason that HASH_EXECUTABLES_ONLY eventually
got added, because the "every entry in every directory" part tends to
be too aggressive for some path elements.

Historically, HASH_CMDS predates HASH_DIRS by several years, and the
documentation for the former still uses the wording that encompassed
that state.