From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17343 invoked from network); 1 Oct 1999 02:12:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Oct 1999 02:12:22 -0000 Received: (qmail 25477 invoked by alias); 1 Oct 1999 02:12:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8119 Received: (qmail 25469 invoked from network); 1 Oct 1999 02:12:16 -0000 From: "Bart Schaefer" Message-Id: <991001021154.ZM25595@candle.brasslantern.com> Date: Fri, 1 Oct 1999 02:11:54 +0000 In-Reply-To: <19990929020225.A21607@adore.lightlink.com> Comments: In reply to Paul Kimoto "Re: command-spelling correction strangeness" (Sep 29, 2:02am) References: <19990928235656.A22062@perdita.antigonus.net> <990929053943.ZM22102@candle.brasslantern.com> <19990929020225.A21607@adore.lightlink.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Paul Kimoto Subject: Re: command-spelling correction strangeness Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 29, 2:02am, Paul Kimoto wrote: } Subject: Re: command-spelling correction strangeness } } On Wed, Sep 29, 1999 at 05:39:43AM +0000, Bart Schaefer wrote: } > However, if you have the hashcmds option set, the rest of the path is } > searched and the correct location gets immediately added back again -- } > so you do not set hashcmds. Am I correct? } } Yes (as you may have seen in my "zsh -f" demonstration). That's actually puzzling, because when I run "zsh -f" for 3.1.6-pws-6, all of hashcmds, hashdirs, and hashlistall are set. Does your /etc/zshenv unset these, perhaps? } I am now a little mystified by the documentation where it says: } } : HASH_CMDS } : 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, no } ^^^^^^^^^^^^^^^^^^^^^^^^^^^ } : path hashing will be done at all. } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The manual is only partly correct, because ... } > I'd be just as } > happy with encouraging people not to use "correct" without "hashcmds" ... ... it turns out that the implementation of "correct" causes hashing to occur, in which case the setting of hashdirs is respected independently of hashcmds. Given that "correct" silently causes hashing to occur, I think the patch that I posted is a necessary one. zsh-workers: Should the doc be updated to reflect that "correct" overrides "nohashcmds"? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com