[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Build break - commaizenumber
On Tue, Mar 15, 2011 at 10:38:02AM -0600, Sverre Froyen wrote:
> > On Tue, Mar 15, 2011 at 04:47:27PM +0100, Martin Husemann wrote:
> > > On Tue, Mar 15, 2011 at 10:44:42AM -0500, Eric Haszlakiewicz wrote:
> > > > Especially so since the thousands separator isn't consistently set.
> > > > e.g. the es locale sets it, but es_ES.UTF-8 doesn't. ja_JP.UTF-8 sets
> > > > it but ja doesn't. etc...
> > >
> > > Yes, that is the part we need to fix. But using something like a hard
> > > coded comma in a locale that does not use "," as a thousands separator
> > > does not help.
> > Using whatever is set even if it's not a "," is the whole point of looking
> > it up based on the locale, but if a locale doesn't configure anything for
> > a thousands separator, why wouldn't we want to use a default?
> Let me expand the perspective a little bit. Unix command output is not just
> meant for human consumption but is just as often used as input by other
> commands. I need to use utf-8 as my default character encoding so I set
> I have seen examples of pkgsrc packages failing to build until I unset
> LC_CTYPE -- presumably because of unexpected commas in numbers. Forcing this
> behavior would obviously exacerbate the problem.
AFAIK there's no way to say "I want to use UTF-8, but w/o all the other locale
stuff", so in a general sense we're SOL. I can think of some ways to try to
fix this, but how about if we keep that to a separate thread?
However, for /bin/ls the behaviour is certainly not forced: you need to
explicitly turn it on with the -M option. The default is still the regular,
"easily" machine parsable output.
Main Index |
Thread Index |