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 > part of the current locale.
Good catch. I went by the bc man page that Dennis Williamson posted.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
signature.asc
Description: OpenPGP digital signature
