Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: command-spelling correction strangeness
- X-seq: zsh-workers 8121
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Paul Kimoto <kimoto@xxxxxxxxxxxxx>
- Subject: Re: command-spelling correction strangeness
- Date: Fri, 1 Oct 1999 16:32:03 +0000
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <19991001002659.A3777@xxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <19990928235656.A22062@xxxxxxxxxxxxxxxxxxxxx> <990929053943.ZM22102@xxxxxxxxxxxxxxxxxxxxxxx> <19990929020225.A21607@xxxxxxxxxxxxxxxxxxx> <991001021154.ZM25595@xxxxxxxxxxxxxxxxxxxxxxx> <19990930232303.A5982@xxxxxxxxxxxxxxxxxxxxx> <991001040228.ZM25695@xxxxxxxxxxxxxxxxxxxxxxx> <19991001002659.A3777@xxxxxxxxxxxxxxxxxxx>
On Oct 1, 12:26am, Paul Kimoto wrote:
} Subject: Re: command-spelling correction strangeness
}
} On Fri, Oct 01, 1999 at 04:02:27AM +0000, Bart Schaefer wrote:
} > Did you try my patch? Did it make any difference to the behavior you
} > see? [...] I couldn't reproduce anything like what you
} > were seeing unless I unsetopt hashcmds.
}
} Your suspicion is right -- your patch doesn't make a difference:
} sorry for misleading you.
OK, the real scoop: My diagnosis was correct as far as it went, but I
missed one detail, which is that even when hashcmds is set it's possible
for `pathchecked' (zsh's internal pointer to how much of the path it has
searched) to already have advanced beyond the directory containing the
actual command. In that case resuming the check where it left off is not
sufficient.
Zsh's internal Cmdnam structure holds a pointer to the spot in the path
where the command was found, so it's possible to restart the search from
there, and I actually had that implemented for a bit; but it occurred to
me that the reason the command can't be executed might be because it was
moved to another place in the path, in which event the search ought to be
started over from the beginning. This works because hashing of a single
command does a test for executable-non-directory-ness, whereas hashing an
entire directory simply stuffs every entry into the table. (So the whole
problem can be avoided in the first place by "unsetopt hashdirs".)
This goes on top of the previous patch. Arguably, removing the hash node
could also be conditional on (flags & HASHED) -- that is, don't implicitly
remove it if the user explicitly hashed it -- but I can't think of any
good reason to deliberately hash a bogus command location.
Index: exec.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/exec.c,v
retrieving revision 1.59
diff -c -r1.59 exec.c
--- exec.c 1999/09/30 15:45:44 1.59
+++ exec.c 1999/10/01 16:19:30
@@ -1692,19 +1692,23 @@
if (!hn) {
/* Resolve external commands */
char *cmdarg = (char *) peekfirst(args);
+ char **checkpath = pathchecked;
int dohashcmd = isset(HASHCMDS);
hn = cmdnamtab->getnode(cmdnamtab, cmdarg);
if (hn && trycd && !isreallycom((Cmdnam)hn)) {
+ if (!(((Cmdnam)hn)->flags & HASHED)) {
+ checkpath = path;
+ dohashcmd = 1;
+ }
cmdnamtab->removenode(cmdnamtab, cmdarg);
cmdnamtab->freenode(hn);
hn = NULL;
- dohashcmd = 1;
}
if (!hn && dohashcmd && strcmp(cmdarg, "..")) {
for (s = cmdarg; *s && *s != '/'; s++);
if (!*s)
- hn = (HashNode) hashcmd(cmdarg, pathchecked);
+ hn = (HashNode) hashcmd(cmdarg, checkpath);
}
}
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author