From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27688 invoked from network); 22 Nov 1999 20:03:47 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 Nov 1999 20:03:47 -0000 Received: (qmail 3739 invoked by alias); 22 Nov 1999 20:03:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8737 Received: (qmail 3732 invoked from network); 22 Nov 1999 20:03:41 -0000 Subject: Re: PATCH: math and locale In-Reply-To: <991122182320.ZM22621@candle.brasslantern.com> from Bart Schaefer at "Nov 22, 1999 6:23:20 pm" To: schaefer@candle.brasslantern.com (Bart Schaefer) Date: Mon, 22 Nov 1999 20:03:39 +0000 (GMT) Cc: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Bart Schaefer wrote: >Glancing through /usr/X11R6/lib/X11/locale/locale.alias I see that the >"POSIX" locale is an alias for the "C" locale, so it probably doesn't >really matter either way. Anyone else have an opinion? Zefram, perhaps? Well since you asked... "C" is probably to be preferred, because it will be available in *all* locale implementations, whereas the "POSIX" locale is a POSIXism. However, where the locale is already "POSIX", presumably we wouldn't need to change that, if we're making setting it conditional -- I don't have the standard to hand, but I'd be very surprised if it defined a different numeric form. Data point: setlocale(3) on Linux indicates that "C" and "POSIX" are canonically equivalent. >} > Where *exactly* would LC_NUMERIC make any difference in pws-9 ? Here we run into one of the big conceptual problems with locales. Are we outputting human text or machine data? There's a need for both. locale-aware programs need to consider which category each output falls into, and perform conversions appropriately. Unfortunately, the C locale system provides no way to switch locale on a per-conversion basis -- not even separate interfaces to perform conversions in the "C" and current locales. This is where it all falls down, and programmers like me just throw up our hands and give up until we're provided with a usable interface. 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. We can fabricate a set of functions like glibc's strtod_l() (perform strtod() using locale X) to make it easier. Problem: we'd get ambiguous cases. strftime() is particularly nasty in this respect. However, following this path, we could make the whole locale thing much easier for the users of zsh: we could provide interfaces where the user specifies whether to use locales or not. ztrftime() could allow a flag in % sequences to say "use the "C" locale for this expansion". Opinions? -zefram