Re: Possible bug: HASH_CMDS has no observable effect

[Roman Perepelitsa <roman.perepelitsa@gmail.com>]

On Fri, Sep 11, 2020 at 6:10 PM Phil Pennock
<zsh-workers+phil.pennock@spodhuis.org> wrote:
>
> 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.

Thanks for the clarification. I've read your post once again and I
don't understand how it explains the observed behavior.

Firstly, let's dispense with the long option description to avoid the
red herring of CORRECT. Here's a shortened version that removes
clauses that don't apply:

  Note the location of each command the first time it is executed.
  Subsequent invocations of the same command will use the saved
  location, avoiding a path search. If this option is unset,
  [irrelevant because this option is set]. However, when CORRECT is
  set, [irrelevant because CORRECT is not set].

And here are the important parts of the commands I ran:

1. The first execution of rsync. It prints version plus help; I've
truncated the latter.

  # rsync
  rsync  version 3.1.2  protocol version 31

2. Check whether rsync is hashed. It appears not to be.

  # print $+commands[rsync]
  0
  # hash | grep rsync
  #

Why isn't rsync hashed the first time it's executed?

Roman.