zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Paul Kimoto <kimoto@lightlink.com>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: command-spelling correction strangeness
Date: Fri, 1 Oct 1999 16:32:03 +0000	[thread overview]
Message-ID: <991001163203.ZM28059@candle.brasslantern.com> (raw)
In-Reply-To: <19991001002659.A3777@adore.lightlink.com>

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


  parent reply	other threads:[~1999-10-01 17:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-29  3:56 Paul Kimoto
1999-09-29  5:39 ` Bart Schaefer
1999-09-29  6:14   ` Paul Kimoto
     [not found]   ` <19990929020225.A21607@adore.lightlink.com>
1999-10-01  2:11     ` Bart Schaefer
     [not found]       ` <19990930232303.A5982@perdita.antigonus.net>
     [not found]         ` <991001040228.ZM25695@candle.brasslantern.com>
     [not found]           ` <19991001002659.A3777@adore.lightlink.com>
1999-10-01 16:32             ` Bart Schaefer [this message]
1999-10-01 19:09               ` Paul Kimoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=991001163203.ZM28059@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=kimoto@lightlink.com \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).