Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Possible bug: HASH_CMDS has no observable effect
On Fri, Sep 11, 2020 at 6:10 PM Phil Pennock
<zsh-workers+phil.pennock@xxxxxxxxxxxx> 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.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author