From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6839 invoked from network); 28 Sep 1998 11:09:35 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 28 Sep 1998 11:09:35 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id HAA00856; Mon, 28 Sep 1998 07:02:44 -0400 (EDT) Resent-Date: Mon, 28 Sep 1998 07:02:44 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980928040555.ZM796@candle.brasslantern.com> Date: Mon, 28 Sep 1998 04:05:55 -0700 In-Reply-To: <199809280902.LAA22135@hydra.ifh.de> Comments: In reply to Peter Stephenson "Re: AUTO_CD (-J) with CDPATH problems" (Sep 28, 11:02am) References: <199809280902.LAA22135@hydra.ifh.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: AUTO_CD (-J) with CDPATH problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"oLxgt3.0.JD.Jps3s"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4400 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Sep 28, 11:02am, Peter Stephenson wrote: } Subject: Re: AUTO_CD (-J) with CDPATH problems } } The problem arises if the command name `prom' is hashed, i.e. in zsh's } internal tables of where commands are to be found. For some reason, } this will happen even to subdirectories of a directory of $path --- } the whole of a directory in $path, not just commands, are added to the } command hash table. [...] } } I know the same feature has been causing trouble with completion for } some time, but this seems to be the last straw. This is even more annoying in the NT port of zsh, because of course the DLLs and data files and whatnot all live in the same directories as the associated executables, so you end up with a -huge- hash table stuffed with useless junk. (Unfortunately, a stat()-based fix is of limited usefulness in that case, because executability is generally a property of the filename extension only.) } [...] did anybody ever check how } much slower it was to stat() the entire directory when adding it to } the command hash table? It probably depends on whether some elements of the path are on NFS servers, and various other local details. I think it's best left alone, or made an option (urk). } I can make a minimal patch just for AUTO_CD when the single } stat()/access() is cheap, of course (in fact I've got one), but I'd } prefer to attack the root cause if possible. There are a few possible approaches short of examining every file in $path at hashing time. One would be to examine only files for which there is an equivalent name in $cdpath or later in $path, i.e., only stat() when disambiguation is necessary. Combined with the patch you just described, that would also catch cases where a subdirectory was added to a directory in $cdpath after hashing. (Also, I'd avoid putting in the command hash table anything that was already in the named directory hash table, or that was directly included in $path or $cdpath.) Except for the above and stray non-commands showing up in completions, are there other cases where junk in the command hash causes problems? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com