On 7/12/19 3:22 PM, Eli Schwartz wrote:
On 7/12/19 3:16 PM, Chet Ramey wrote:
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.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html#tag_20_09_16
"The bc utility always uses the <period> ( '.' ) character to represent
a radix point, regardless of any decimal-point character specified as
Imagine that ... learn something new from something very old :
corv $ locale -a | grep -i 'utf' | grep 'fr'
fr.UTF-8
fr_BE.UTF-8
fr_BE.UTF-8@euro
fr_CA.UTF-8
fr_CH.UTF-8
fr_FR.UTF-8
fr_FR.UTF-8@euro
fr_LU.UTF-8
corv $
corv $ LC_ALL=fr_FR.UTF-8 bc
scale=8
a = 0,1
syntax error on line 2, teletype
a = 0.1
b = 0.01
c = a + b
c
.11
corv $
corv $ LC_ALL=fr_FR.UTF-8 /usr/xpg6/bin/bc -l
a = 0,1
syntax error on line 1, teletype
a = 0.1
b = 0.01
c = a + b
c
.11
c(c)
.99395609795669685035
corv $
Well now. That is XPG6 compliant bc on Solaris 10 sparc.
It could care less about locale it seems. Nifty.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
