From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16275 invoked from network); 7 Dec 1998 16:20:55 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 7 Dec 1998 16:20:55 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id LAA12577; Mon, 7 Dec 1998 11:20:04 -0500 (EST) Resent-Date: Mon, 7 Dec 1998 11:17:48 -0500 (EST) From: "Bart Schaefer" Message-Id: <981207081603.ZM989@candle.brasslantern.com> Date: Mon, 7 Dec 1998 08:16:03 -0800 In-Reply-To: <19981207144447.A13964@math.fu-berlin.de> Comments: In reply to Stucki "How to NOT allow LC_COLLATE to corrupt globbing ???" (Dec 7, 2:44pm) References: <19981207144447.A13964@math.fu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Stucki , zsh-users@math.gatech.edu Subject: Re: How to NOT allow LC_COLLATE to corrupt globbing ??? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"N0p1b3.0.d23.h-_Qs"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1963 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Dec 7, 2:44pm, Stucki wrote: } Subject: How to NOT allow LC_COLLATE to corrupt globbing ??? } } Once again I nearly was bitten by an Environment containing: } export LC_COLLATE=de } } Then doing 'rm *[A-Z]*' on a Sun is really doing 'rm *' } as there is no difference between upper and lower case } in the german collating sequence. When we discussed this earlier this year, Zoltan concluded in http://www.zsh.org/mla/workers/1998/msg00551.html that GNU regexp and bash don't use the collating sequence in character ranges, and that it's therefore probably OK for zsh not to either. Hey, Tim, any chance you can try ksh in some other language environment to see if it collates character ranges? } So now I'd like to ***compile*** my zsh in a way that makes sure } I *always* use the standard collating sequence like LC_COLLATE=C } (or may be LC_COLLATE=us). } } (changing 'config.h' *after* running 'configure' } to contain '#define HAVE_LOCALE_H 0' did *not* help!) That's because glob.c calls strcoll() if HAVE_STRCOLL is defined, whether or not locale.h is present or any other locale macros are defined. So if the library strcoll() believes LC_COLLATE, you're going to get collating behavior. Contrariwise, if you #undef HAVE_STRCOLL you'll get the rest of the locale-specific behavior without getting collating sequences. There are other places where HAVE_STRCOLL is used and might be desirable, though, so it would really be best to make a decision on glob.c and either remove the HAVE_STRCOLL code or make it part of the appropriate emulation. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com