From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1512 invoked from network); 29 Sep 1999 06:14:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Sep 1999 06:14:21 -0000 Received: (qmail 15308 invoked by alias); 29 Sep 1999 06:14:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8092 Received: (qmail 15300 invoked from network); 29 Sep 1999 06:14:13 -0000 From: Paul Kimoto Date: Wed, 29 Sep 1999 02:14:08 -0400 To: zsh-workers@sunsite.auc.dk Subject: Re: command-spelling correction strangeness Message-ID: <19990929021408.A22412@perdita.antigonus.net> References: <19990928235656.A22062@perdita.antigonus.net> <990929053943.ZM22102@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <990929053943.ZM22102@candle.brasslantern.com> [This is a copy of a message sent to Bart Schaefer that I Cc'ed to zsh-workers before remembering that I was on a ORBS-tainted site whose mail is rejected by sunsite.auc.dk.] On Wed, Sep 29, 1999 at 05:39:43AM +0000, Bart Schaefer wrote: > A change was made about a year ago (zsh-workers/4404 and follow-ups) to > remove entries for non-executable files from the command hash table. > This happens only when "autocd" is set, because the only bad side effect > of bogus hash table entries is that if they're directories rather than > non-executable files, you can't autocd into them. > > 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? [detailed explanation snipped] Yes (as you may have seen in my "zsh -f" demonstration). The explanation is plausible. 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (I admit that I have read only the documentation, not the source code.) > So ... what you describe may or may not be a bug, but the following should > cause the command table to be updated more intelligently. I'd be just as > happy with encouraging people not to use "correct" without "hashcmds" ... It could be added to the documentation .... [patch snipped] -Paul