From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2521 invoked by alias); 7 Jan 2012 07:17:27 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30099 Received: (qmail 15057 invoked from network); 7 Jan 2012 07:17:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120106231700.ZM17143@torch.brasslantern.com> Date: Fri, 06 Jan 2012 23:17:00 -0800 In-reply-to: Comments: In reply to Greg Klanderman "Re: zsh hangs loading init files" (Jan 6, 8:27pm) References: <20229.54117.22089.85103@gargle.gargle.HOWL> <20120105193518.GE80751@dan.emsphone.com> In-reply-to: Comments: In reply to Mikael Magnusson "Re: zsh hangs loading init files" (Jan 7, 2:28am) In-reply-to: Comments: In reply to Greg Klanderman "Re: zsh hangs loading init files" (Jan 6, 8:36pm) In-reply-to: Comments: In reply to Mikael Magnusson "Re: zsh hangs loading init files" (Jan 7, 2:56am) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: zsh hangs loading init files MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 6, 8:27pm, Greg Klanderman wrote: } } hmm looks like users/14411 In that message, PWS pondered: > I'm not sure why we don't check that commands are executables, was there > ever a reason? Apparently the answer is "Yeah, if you've got 10,000 executables or a remote filesystem in your path, it takes a really long time to stat them all." On Jan 6, 8:36pm, Greg Klanderman wrote: } } Adding "setopt nohashdirs" gets me past the $(uname -s) quickly, but } then later, accessing $commands[foo] still causes it to go stat() } every file under every element of my path. The zsh/parameter module uses the HASH_LIST_ALL option to determine whether to fill the hash table when referencing $commands. I'm not sure that's documented anywhere ... this is also true for spelling correction, so the part of the HASH_CMDS doc that refers to CORRECT is at least incomplete. Another way to cause the table to be filled is to use "whence -m". On Jan 7, 2:56am, Mikael Magnusson wrote: } } There is no option to disable the stat()ing while filling the hash Perhaps what should have been done is to stat them when reading them back, but that would have required some state bits in the table. An option would be the next best thing. } Incidentally, the manpage says } HASH_DIRS } Whenever a command name is hashed, hash the directory } containing it, as well as all directories that occur } earlier in the path. Has no effect if neither HASH_CMDS } nor CORRECT is set. } } However, setting hashdirs still causes the hash to be filled when both } hashcmds and correct are unset. Hrm. I'm not able to reproduce that from "zsh -f". torch% setopt no${^options[(I)hash*]} torch% hash -r torch% ls ... torch% print $#commands 0 torch% setopt hashdirs torch% ls ... torch% print $#commands 0 torch%