GNU bug report logs - #16838
Confusing localization of seq

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16838 in the body.
You can then email your comments to 16838 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Göran Uddeborg <goeran <at> uddeborg.se>
To: bug-coreutils <at> gnu.org
Subject: Confusing localization of seq
Date: Fri, 21 Feb 2014 23:48:21 +0100

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.

Message #8 received at 16838 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Göran Uddeborg <goeran <at> uddeborg.se>
Cc: 16838 <at> debbugs.gnu.org
Subject: Re: 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.