From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28152 invoked from network); 16 Dec 2008 16:29:10 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 16 Dec 2008 16:29:10 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 88119 invoked from network); 16 Dec 2008 14:42:03 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 16 Dec 2008 14:42:03 -0000 Received: (qmail 18225 invoked by alias); 16 Dec 2008 14:41:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26140 Received: (qmail 18208 invoked from network); 16 Dec 2008 14:41:58 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 16 Dec 2008 14:41:58 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [208.87.233.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id E925F801E288 for ; Tue, 16 Dec 2008 15:41:53 +0100 (CET) Received: from rly23g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly23g.srv.mailcontrol.com (MailControl) with ESMTP id mBGEfMtA006178 for ; Tue, 16 Dec 2008 14:41:50 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly23g.srv.mailcontrol.com (MailControl) id mBGEeuHv002197 for zsh-workers@sunsite.dk; Tue, 16 Dec 2008 14:40:56 GMT Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly23g-eth0.srv.mailcontrol.com (envelope-sender Peter.Stephenson@csr.com) (MIMEDefang) with ESMTP id mBGEetEM001926; Tue, 16 Dec 2008 14:40:56 +0000 (GMT) Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Dec 2008 14:40:54 +0000 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id mBGEenbe007196; Tue, 16 Dec 2008 14:40:49 GMT Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id mBGEelex007193; Tue, 16 Dec 2008 14:40:48 GMT Message-Id: <200812161440.mBGEelex007193@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: "Sean B. Palmer" , zsh-workers@sunsite.dk Subject: Re: Case Sensitivity Bug? In-reply-to: References: Comments: In-reply-to "Sean B. Palmer" message dated "Tue, 16 Dec 2008 14:14:03 +0000." Date: Tue, 16 Dec 2008 14:40:47 +0000 From: Peter Stephenson X-OriginalArrivalTime: 16 Dec 2008 14:40:54.0713 (UTC) FILETIME=[4CE86A90:01C95F8C] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.71.1.133 X-Virus-Scanned: ClamAV 0.92.1/8767/Tue Dec 16 14:52:17 2008 on bifrost X-Virus-Status: Clean "Sean B. Palmer" wrote: > zsh is doing something very strange on OS X: > > $ zsh -c 'echo test; which head' > test > /opt/local/bin/head > > $ zsh -c 'date; which head' > Tue Dec 16 13:57:00 GMT 2008 > /usr/bin/head > > The problem centres around the case-sensitivity of HFS+, the OS X > filesystem. I have two head binaries, one called "head", the standard > unix head, and one called "HEAD", part of perl's lwp library: > > $ which head > /usr/bin/head > > $ which HEAD > /opt/local/bin/HEAD > > As you can see from the echo and date commands, my problem is that > invoking echo first in the shell (or invoking nothing at all) causes > which to work in a case insensitive manner. When date is invoked first > instead, which works in a case sensitive manner. > > Why is this so? I think it's down to command hashing. In the second case "date" is an external command and zsh will fill its hash of external commands as it searches the path to find date. The which command then relies on this. In this case the shell is comparing the command you searched for against an internal string, which is case sensitive. A corollary is likely to be that command completion is case sensitive by default (though completion is powerful enough for you to fix this fairly generally), since this uses the hash, too. In the first case, there's no hash; "which" does a blind search of the path for /head by trying to access the file and /opt/local/bin/HEAD matches because the comparison is done in the file system driver. This is inconsistent, so regardless of what the right answer for case sensitivity is, this isn't it. Command hashing isn't really appropriate if searching is done case insensitively, at least not without a flag saying the command is stored on a case insensitive system, which the shell doesn't know. Hence the easiest fix (without actually looking at the code) is likely to be to make the code fully case insensitive by adding a string comparison in the case where which searches the path itself. > And how does zsh manage to implement a case sensitive > which at all? Your file system is case preserving as well as case insensitive, so a file name read from the disk will have a certain format which the shell will use when it does string comparisons. > Neither sh and bash on OS X have a case sensitive which. > I'm using OS X 10.4.11 (Tiger). So they're not doing that. There's an argument that command hashing is unnecessary on modern systems anyway, although the way it's wired into the completion system means this is a little different in zsh from most shells. A trivial way of guaranteeing that "which" is case insensitive is to use pattern matching. This would remain even if in future we guaranteed that the default string match was case sensitive. % setopt extendedglob % which -m '(#i)head' /usr/bin/HEAD /usr/bin/head (here on Fedora 8, hence file system is actually case sensitive). -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070