numfmt: locale/grouping input issue

[Assaf Gordon]

Hello,

(Continuing a previously discussed issue - accepting input values with locale 
grouping separators)

>Pádraig Brady wrote, On 12/07/2012 01:09 PM:
>> On 12/07/2012 03:07 PM, Assaf Gordon wrote:
>>> Another thing I thought of there, was it would be
>>> good to be able to parse number formats that it can generate:
>>
>> Sounds like two separate (but related) issues:
>>
>>> $ echo '1,234' | src/numfmt --from=auto
>>> src/numfmt: invalid suffix in input '1,234': ',234'
>>
>> 1. Is there already a gnulib function that can accept locale-grouped values? 
>> can the "xstrtoXXX" functions handle that?
> 
> I was thinking you would just strip out
> localeconv()->thousands_sep before parsing.

I couldn't find an example of a coreutil program that readily accepts locale'd 
input.
The while dots and commas (US/DE locales) are relatively easy to handle, in the 
french locale the separator is space - causing a conflict when assuming the 
default field separator is also white space.

Another complication is that just stripping out the 'thousands_sep' character 
would treat text such as "1,3,4,5,6" as valid number "13456" .

I would suggest at first not to accept locale'd input, or only offer partial 
support.
WDYT ?

Thanks,
 -gordon


Couple of examples:

   # Output is OK
   $ LC_ALL=fr_FR.utf8 ./src/printf "%'d\n" 1000
   1 000

   # Input is not valid
   $ LC_ALL=fr_FR.utf8 ./src/printf "%'d\n" "1 000"
   ./src/printf: 1 000 : valeur non complètement convertie
   1

   # Sort can't handle locale'd input, treats the white-space as separator,
   #  not as "thousand separator".
   $ printf "1 123\n1 000\n" | LC_ALL=fr_FR.utf8 sort --debug -k1,1 
   sort: utilse les règles de tri « fr_FR.utf8 »
   sort: leading blanks are significant in key 1; consider also specifying 'b'
   1 000
   _
   _____
   1 123
   _
   _____