From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11340 invoked from network); 23 Nov 1999 18:18:35 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 Nov 1999 18:18:35 -0000 Received: (qmail 10443 invoked by alias); 23 Nov 1999 18:18:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8758 Received: (qmail 10436 invoked from network); 23 Nov 1999 18:18:28 -0000 From: "Bart Schaefer" Message-Id: <991123181821.ZM29713@candle.brasslantern.com> Date: Tue, 23 Nov 1999 18:18:21 +0000 In-Reply-To: Comments: In reply to Zefram "Re: PATCH: math and locale" (Nov 22, 8:03pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: math and locale MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 22, 8:03pm, Zefram wrote: } Subject: Re: PATCH: math and locale } } If we do wish zsh itself to use locales, I see several possibilities: } } * We can do what POSIX defines for most utilities (not sure what it } says about sh): guarantee sensible behaviour in the "POSIX" locale, } and leave it undefined everywhere else. Strictly speaking, if you } want the standard form of output from most POSIX utilities, you have } to set LC_ALL=POSIX for it. } } * We can use the selected locale for LC_MESSAGES, which only affects } things that are definitely for human consumption, and leave everything } else using the "C" locale. This would have almost exactly the desired } effect for zsh, and is trivially easy to implement. } } * We can try to do it properly: decide which things should be } locale-dependent and which shouldn't. It sounds like we already have the first one, that the second one might be preferable, and that the third one is going to be hard to implement and even harder to document clearly. I suggest that we first find out what POSIX says about shells in this regard (Zoltan? Are you out there?), and then choose whichever of the first two gets us closest to that. Then we worry about how to get all the way to POSIX (if we aren't) *after* the next major release (3.2 or whatever it will be, not the next 3.1.x). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com