Re: [RFC or so] Add HASH_LOOKUP option

[Mikael Magnusson <mikachu@gmail.com>]

So I'm trying to remember why I put off finishing this. :) Sorry if I
ask something I've already asked, it appears to have been a while. I
haven't yet looked at the actual code again.

On 23 August 2010 19:46, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 23,  4:09pm, Mikael Magnusson wrote:
> }
> } When this is unset, external commands are always resolved with a full
> } path search, but still inserted into the hash for spell correction if
> } those options are on.
> }
> } diff --git a/Src/exec.c b/Src/exec.c
> } index 93d1b26..9a488fe 100644
> } --- a/Src/exec.c
> } +++ b/Src/exec.c
> } @@ -754,7 +754,7 @@ findcmd(char *arg0, int docopy)
> }           }
> }           break;
> }       }
> } -    if (cn) {
> } +    if (cn && isset(HASHLOOKUP)) {
> }       char nn[PATH_MAX];
> }
> }       if (cn->node.flags & HASHED)
>
> I think there may be  problem with this in the event that the "hash"
> command has been used to deliberately insert an entry into the hash
> table.  That's a documented mechanism for overriding path search.

[and in a later reply]
> However, and this might be considered a bug, changing the value of
> $path discards the entire hash table, including entries that have been
> explicitly inserted with "hash".

Setting the rehash style to true also overrides this mechanism.
% zstyle \* rehash true
% echo $options[hashlookup]
on
% hash urxvt=/bin/false
% urxvt
[returns false, no terminal appears]
% urxv<tab, t appears><enter>
[terminal pops up]
Without the rehash style set at this point, it will still return false
instead of starting urxvt.

> } > [**] The HASHED bit means the command was deliberately inserted into
> } > the hash table with the "hash" builtin, rather than found by search.
> } > In this case the both findcmd() and execute() are forced to believe
> } > what the hash table tells them.
> }
> } Could this be used, theoretically, to still allow users to override
> } the path, and still do a full path search for search hashed entries?
>
> I'm not sure what you mean, but on my best guess:  If you poke into
> the hash table with "hash foo=/xyz/foo" then the "foo" command will
> run /xyz/foo even if ${^path}/foo(N) is non-empty.

What I mean is that with the patch, and setopt nohashlookup active,
doing hash urxvt=/bin/ls and then attempting to run urxvt, will still
run /usr/bin/urxvt (or wherever it's found). It would possibly be nice
if nohashlookup meant that if you add a binary earlier in your $path,
then it is automatically picked up despite being automatically hashed,
but if you inserted it manually with the hash builtin, it is not
picked up.

It would (maybe?) be nice if we would do a path search for a command
not in the hash before attempting to correct it, to avoid the problem
where you install something similar-sounding and zsh wants to correct
it to something else, and you have to answer 'n'. Maybe this is
orthogonal and should happen regardless of the setting of HASH_LOOKUP?

-- 
Mikael Magnusson