Re: built-in printf %f parameter format depend on LC_NUMERIC

From	Léa Gris <lea.gris@noiraude.net>
Newsgroups	gnu.bash.bug
Subject	Re: built-in printf %f parameter format depend on LC_NUMERIC
Date	2019-07-12 18:46 +0200
Message-ID	<mailman.1030.1562950014.2688.bug-bash@gnu.org> (permalink)
References	<5d24be33.1c69fb81.59c43.fe4dSMTPIN_ADDED_BROKEN@mx.google.com> <a212b38c-914d-dda6-8d22-e9039063768e@case.edu> <6468b45e-5b4a-8edf-4ab8-0838843beaaf@noiraude.net> <b6f65b6b-1487-0c46-6530-fa6d700ff1ca@case.edu> <7c757690-24bd-7b1a-cf8e-af63cbe05216@noiraude.net>

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Le 09/07/2019 à 22:02, Chet Ramey écrivait :

> These are up to the system's strtol/strtod. I don't know of too many
> strtol implementations that use the thousands separator and numeric
> grouping.

Chet and you other Bash maintainers or contributors dudes:

I can foresee the implications and blockages even lightly considering 
the possibility to align the Bash's built-in printf behavior with the %f 
argument with the sibling GNU Coreutils printf implementation.

Anyway, I hope this topic to remain a place for sane discussions about 
the implications of Bash's printf implementation for numerical data 
interoperability while allowing display and printout to user locale format.

Because it help myself in a positive way, I'd like to share my free 
software contribution with a small lcnumconv.sh library I made available 
here:

https://github.com/leagris/lcnumconv.sh

The README exposes the incentives behind this library/stand-alone 
command, that may shed some light on how the Bash's printf 
implementation of the %f format can be an issue.

Be glad if it can helps in some way.

Do what the F** you want with it :)

-- 
Léa Gris

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: built-in printf %f parameter format depend on LC_NUMERIC Léa Gris <lea.gris@noiraude.net> - 2019-07-12 18:46 +0200

csiph-web