[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16838: Confusing localization of seq

From: Pádraig Brady
Subject: bug#16838: Confusing localization of seq
Date: Sat, 22 Feb 2014 01:54:34 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]