Re: Possible bug: HASH_CMDS has no observable effect

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Sep 12, 2020 at 1:49 AM Roman Perepelitsa
<roman.perepelitsa@xxxxxxxxx> wrote:
>
> On Sat, Sep 12, 2020 at 10:35 AM Bart Schaefer
> <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > The whole search-and-cache process is
> > short-circuited.
>
> Doesn't this search happen anyway? When I type `rsync`, it gets
> resolved as /usr/bin/rsync and gets executed. This requires searching
> for rsync in all path directories.

The cache is a mapping from command names to locations.  So,  if
"rsync" is in the cache, then the value of that cache entry is
"/usr/bin/rsync" and zsh just executes that without scanning the path
again.  Conversely if HASH_DIRS is set and "rsync" is NOT in the
cache, but everything else from /usr/bin IS in the cache (as a
byproduct of some previous search), zsh reports command not found,
again without re-scanning the path.

HASH_DIRS is done incrementally, e.g., if your path is "/bin:/usr/bin"
and you first execute a command from /bin, zsh only populates the
cache with commands in /bin, and remembers that it has not looked in
/usr/bin yet.  If you then execute "rsync", a cache miss causes
HASH_DIRS to scan /usr/bin, add everything there to the cache, and
execute /usr/bin/rsync.

Eventually every directory in the path will have been scanned, and
cache misses become immediately "not found".  If HASH_DIRS is not set
(but HASH_CMDS is).

> I believe this is done in execute()
> in Src/exec.c. Wouldn't it be better to search for `rsync` in the
> parent shell (before forking) and hash the result?

That's exactly how it works.  The search in execute() is only done if
an absolute file location for the command isn't provided by the
parent, which only occurs if HASH_CMDS is not set.

This does mean that if a command is removed from (or moved within) the
path, execute() will be handed an invalid file location and will fail.
Again, for most users this never happens.