Re: numfmt: locale/grouping input issue

[Pádraig Brady]

On 12/11/2012 07:03 PM, Pádraig Brady wrote:
> On 12/11/2012 06:36 PM, Assaf Gordon wrote:
> > 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.
>
> True. You could only support that when --delimiter was not ' ',
> or when LC_NUMERIC was set to one with a non space grouping char.
>
> > 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" .
>
> Good point. You'd need to count as well as strip

And the counting shouldn't really hardcode 3
and instead honor locale_conv()->grouping.
For example:

$ LC_ALL=ta_IN locale grouping
3;2

$ LC_ALL=ta_IN printf "%'d\n" 123456789
12,34,56,789

cheers,
Pádraig.