From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1166 invoked from network); 29 Sep 1999 05:40:16 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Sep 1999 05:40:16 -0000 Received: (qmail 13579 invoked by alias); 29 Sep 1999 05:40:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8091 Received: (qmail 13572 invoked from network); 29 Sep 1999 05:40:08 -0000 From: "Bart Schaefer" Message-Id: <990929053943.ZM22102@candle.brasslantern.com> Date: Wed, 29 Sep 1999 05:39:43 +0000 In-Reply-To: <19990928235656.A22062@perdita.antigonus.net> Comments: In reply to Paul Kimoto "command-spelling correction strangeness" (Sep 28, 11:56pm) References: <19990928235656.A22062@perdita.antigonus.net> X-Mailer: Z-Mail (5.0.0 30July97) To: Paul Kimoto , zsh-workers@sunsite.auc.dk Subject: Re: command-spelling correction strangeness MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 28, 11:56pm, Paul Kimoto wrote: } Subject: command-spelling correction strangeness } } I have a non-executable, non-zero-size file "ps" } (-rw-r--r-- 1 kimoto kimoto 268 Mar 30 16:44 ps) } in a directory ahead of /bin in PATH. When I have the "correct" and } "autocd" options set, often zsh offers to correct "ps" to "ls" _after_ } "ps" has been run once. 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? Here's what happens: Running any external command causes the command hash table to be filled. Because the non-executable "ps" is in $PATH ahead of /bin, it gets added to the hash table and /bin/ps does not. Later, you run "ps". The hash entry for "ps" is found to point to the non-executable file and is therefore deleted from the hash table. Now there is no entry for "ps" at all; "/bin/ps" is found by re-searching the path, but this is not added to the hash table. Finally, you run "ps" again. Zsh looks in the hash table and doesn't find it, so it picks the next closest thing (for a keyboard-oriented definition of `closest') and asks whether it should correct to that. On my system it chooses "psf" which is some kind of postscript print filter, but on your system it must be "ls". 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" ... Index: Src/exec.c =================================================================== @@ -1697,14 +1697,16 @@ if (!hn) { /* Resolve external commands */ char *cmdarg = (char *) peekfirst(args); + int dohashcmd = isset(HASHCMDS); hn = cmdnamtab->getnode(cmdnamtab, cmdarg); if (hn && trycd && !isreallycom((Cmdnam)hn)) { cmdnamtab->removenode(cmdnamtab, cmdarg); cmdnamtab->freenode(hn); hn = NULL; + dohashcmd = 1; } - if (!hn && isset(HASHCMDS) && strcmp(cmdarg, "..")) { + if (!hn && dohashcmd && strcmp(cmdarg, "..")) { for (s = cmdarg; *s && *s != '/'; s++); if (!*s) hn = (HashNode) hashcmd(cmdarg, pathchecked); -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com