Re: Build break - commaizenumber

[Eric Haszlakiewicz <erh%nimenees.com@localhost>]

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
> 
> LC_CTYPE=en_US.UTF-8
> 
> 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.

eric