Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15136 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

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

[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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web