From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21799 invoked by alias); 23 Aug 2010 14:55:46 -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: 28194 Received: (qmail 25622 invoked from network); 23 Aug 2010 14:55:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Mon, 23 Aug 2010 15:55:27 +0100 From: Peter Stephenson To: zsh workers Subject: Re: [RFC or so] Add HASH_LOOKUP option Message-ID: <20100823155527.6e11c3bf@csr.com> In-Reply-To: References: Organization: Cambridge Silicon Radio X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2010 14:55:27.0512 (UTC) FILETIME=[392F3980:01CB42D3] X-Scanned-By: MailControl A_09_40_00 (www.mailcontrol.com) on 10.71.0.134 On Mon, 23 Aug 2010 16:09:45 +0200 Mikael Magnusson wrote: > When this is unset, external commands are always resolved with a full > path search, but still inserted into the hash for spell correction if > those options are on. Looks a reasonable thing to be able to do. The word on the streets (for a tiny, tiny subset of streets) has for some time been that modern operating systems do their own optimisation of path lookup such that hashing in the shell doesn't gain you very much. The main reason we haven't done anything about it is that we need the hash for other reasons. You've sidestepped that simply by always searching and still hashing it (depending on the existing options). That's a very minor performance hit beyond the path search, so I can't see any objection. Telling people to turn it off is probably the big problem. I'd be sympathetic to turning it off by default if there's enough evidence the performance hit is minor, but that's all rather system-specific, so don't hold your breath. I'd be wary of turning it off by default on Cygwin with paths to remote shares, for example. It would be useful if you could write some tests to go in Test/E01options.ztst. Basically you just need to test the right version of a command is found with it on and off. It would be good to do a test along the lines of mkdir dir1 dir2 mkcmd() { print "#!/bin/sh\necho Command $1" >dir$1/cmd chmod +x dir$1/cmd } mkcmd 2 for opt in on off on off; do if [[ $opt = on ]]; then setopt hashlookup else unsetopt hashlookup fi rm -rf dir1/cmd (path=($PWD/dir1 $PWD/dir2) cmd mkcmd 1 cmd) done and verify that when the option is off the second cmd prints "Command 1" each time round and when it's on it doesn't. (I haven't tested this code.) -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom