From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28288 invoked by alias); 2 Jun 2011 15:11:39 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29437 Received: (qmail 29437 invoked from network); 2 Jun 2011 15:11:36 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.212.43 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vgQg/XymZJ72WNA0N/bGl19VKqCPA5gGmATWWsGHfD0=; b=d46d+8Ovu15XkvblOcxelCnJ7vawEX0ilHSeikUOPn5SLGI6tzOLFlJq5+X8P/jvsN RMt08B3sg4MTXBHWrAEvSk3jVBpExEXjOGoGwqnziU/84tL4eGOQEqmFq5hn1p5P1prG VfOqDTonYcQCz3OrIqyGYz8uGY98BdxOsud98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=r1SBXIkj+6cV6VpPQNzDb6kdFVAavr4KBif2qwLBOD0rR6CNxS0jYRre8ypiPsghYo kGzRysEXs6/BRc9rZGTkIFGCKKfYZEo3x46TS8+FI/TMQjF6QOlW5D7/xFqYUu+QjsHI z492ayr7Ibt+85T/ZaxPYEZV5wuFAM14Vf1K4= MIME-Version: 1.0 In-Reply-To: <100823104610.ZM26959@torch.brasslantern.com> References: <100823104610.ZM26959@torch.brasslantern.com> Date: Thu, 2 Jun 2011 17:11:30 +0200 Message-ID: Subject: Re: [RFC or so] Add HASH_LOOKUP option From: Mikael Magnusson To: zsh workers Content-Type: text/plain; charset=UTF-8 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 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 [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