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

Groups > gnu.bash.bug > #15147 > 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 21:55 +0200

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

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

Le 12/07/2019 à 21:16, Chet Ramey écrivait :
> On 7/12/19 12:46 PM, Léa Gris wrote:
>> 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.
> 
> I don't think I explained this very well. For input, the printf builtin
> relies on strtod(3) to parse the string into a floating point number. For
> output, it relies on printf(3) to display a floating point number as a
> string. I'm not really interested in re-implementing either one if the
> system libc provides one that's perfectly acceptable. On POSIX-conformant
> systems, those library functions generally honor the locale's decimal_point
> character as the radix character.
> 
> The `bc' you're using isn't POSIX conformant.
> 

True, and fortunately this is exactly how I understood your detailed and 
informed explanations for how and why it is this way.

By-the-way, as a user or as a Bash script writer, I am more concerned by 
the portability of the data a Bash script can handle. And for floating 
point numbers data, the one locale format I am sure to exist in any kind 
of the most lightly POSIX compliant systems, is the POSIX or C locale.

If a bc is POSIX compliant, input and output numbers based on the 
locale, then I am almost fine with it. I can still set the locale to 
match the bc script number formats. It would be quite annoying having a 
bc script with numbers formatted to the da_DK locale that works only 
with a POSIX compliant bc command and only on systems with the da_DK 
locale available, but I am sure I can run any bc script that is using 
numbers formatted to the POSIX locale if I switch the local to POSIX 
before running the bc script.

The issue with Bash's printf will spawn later down the line. When I need 
to output floating-point numbers the format of the user locale 
LC_NUMERIC, because human beings will read these numbers rather than 
another computer program. I will also have to provide Bash's printf with 
numbers of this locale format as parameters. I can not count on Bash's 
printf to bridge POSIX locale formatted floating-point numbers to any 
kind of user locale format.

This is exactly here that my modest lcnumconv Bash library can help.
Machine processing, and I count printf arguments as machine processing, 
is best done with POSIX locale formatted numbers.
lcnumconv can also help deal with human input of floating-point numbers 
conversion to POSIX for processing these. Because Bash only know about 
strings and internally about integers. The built-in read can not 
translate floating point numbers to anything. It is just strings of 
characters. In this regard, printf support for floating point numbers is 
an alien ^^.

-- 
Léa Gris

[toc] | [standalone]

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

csiph-web