GNU bug report logs - #16838
Confusing localization of seq

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Göran Uddeborg <goeran <at> uddeborg.se>
Cc: 16838 <at> debbugs.gnu.org
Subject: bug#16838: Confusing localization of seq
Date: Sat, 22 Feb 2014 01:54:34 +0000

On 02/21/2014 10:48 PM, Göran Uddeborg wrote:
> It seems the input arguments of "seq" are not localized, but the
> output is.  I was surprised to find this, and thought I'd ask here if
> it is an intentional decision.
> 
> More specifically, I'm using the Swedish locale, where the radix
> character is a comma.  The arguments to "seq" does not accept a comma,
> but the output is written using it.
> 
>     mimmi$ env LANG=sv_SE.utf8 seq 1 0.3 2
>     1,0
>     1,3
>     1,6
>     1,9
> 
> I realized this using coreutils-8.21 on Fedora.

That is an unfortunate asymmetry, though founded in pragmatism.

Similarly date(1) for example can't parse
the localized output that it can itself generate.

Do we really want to complicate the code
to support the many different numeric formats,
including different grouping sizes, grouping characters,
alternative digits like ۱٬۲۳۴ etc.?

More important to code complexity is the
simplification of the interface by restricting
the input to a subset format and only considering
localized output at the final step for presentation.

Now rather than consider changing these _programmatic_ interfaces,
we might support conversion of localized input in an explicit
entry point to the system.  We could isolate that
functionality in the new numfmt utility, which could
be updated to support these asymmetric localization conversions.

thanks,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.