Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: =?UTF-8?B?TMOpYSBHcmlz?= <lea.gris@noiraude.net>
Newsgroups: gnu.bash.bug
Subject: Re: built-in printf %f parameter format depend on LC_NUMERIC
Date: Fri, 12 Jul 2019 21:55:53 +0200
Lines: 122
Approved: bug-bash@gnu.org
Message-ID: <mailman.1055.1562961362.2688.bug-bash@gnu.org>
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> <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu> <405e525c-278e-7779-3c39-3cf58d4bfa1a@noiraude.net>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qglVH7lZey3kReje2zUkiwACqlo49qHes"
To: chet.ramey@case.edu, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Openpgp: id=2A931E283F202EE5BFCC4F7070946F168078ED52; url=https://www.noiraude.net/8078ED52.asc
Autocrypt: addr=lea.gris@noiraude.net; prefer-encrypt=mutual; keydata= mQINBE8OHUcBEADQjtKQcz/T/msKQcvyWEmBz5aKFGYjdErVABpJAiGqNa9m7kr2P5i7iXR/ nuUswsPlVmRxeIWsAMxoU02cwicRoydEJgbZH6KwXMmAynersG70JIobOXF2g5W683pf1R35 PNjrw3sIiQJgpRi2idL0Fvhp8h78fvHkseaomRg8r8zvOQ4AnbWcywDwbZzDVLrMuEUi27Yh j86RaJDcv6P0ygmMiVFHYFyIDBpl2uVbePanpjT8lwzBCJ1MVzc0Bfyi2W0dYlK1dP5pWeQb kMmizpg4SqF0mMSH1Iq8q9AR+M+eN7K2yzpJ3Nez+GurpAkXEdomCF9CkKQbRRbR+AiZfl6n cJwg0+dhJn70vSwdEyRHlX/39ZZA9v4PC18Ukjf9nY9Bb3vl8M5Mo/g9zHertjPlQcGwOubn 05fuehh7H4kUAPhT0w/6R05gT/lw2e89i7TP/Qxixc00DU6mJX3OEWg23fGt8m22mA92+XQx ZEvAviZSjvj+xL7wP7u9r+4RfNT9N1Ebs9tGXFYIpbBZSKaPFTmzJHILuya+otaFs9DKXRWI 9R3W8sP0YHCEfZpYHoAFfofmC4hZds40z7/msqVJ+2XaPfXsmXCL/juWpYJF3LbPdN87r5UY fqmx3ezTYRofa1pxzZn60fmkFuSUH7qqvKKIdheDlqZI6D3+aQARAQABtC9Mw6lhIEdyaXMg KExhIE5vaXJhdWRlKSA8bGVhLmdyaXNAbm9pcmF1ZGUubmV0PokCOwQTAQIAJQIbAwYLCQgH AwIGFQgCCQoLBBYCAwECHgECF4AFAlAAB+cCGQEACgkQcJRvFoB47VIa2w/7B3S51cvmOPHy rfybG0NdGQzSDRFhvVHXGQC62JMzT+i5fzkRNAk7LCvWS1PBmh79rokf8qhx5xQ/xlBo5IR0 K0yxRXs3Yr90opcu20qKIYjryTqiKkB41XY+oCQXpRqjP2LtkWL52yXMLbqfI4XQ4j2RveE/ HR/+Y4bCtnYZb/O1Y4Cl9gslOK1+xpYWaHHu2yNGgXwFYo4ujryzygmb4i/LMblPHw3nmNTr O4u0jyuejrq7qgrnwM8JQrIuyIOWbdMRPMKOgb8AIsFPLqIvnYcYB8ms/ilcHOjANTE5j/3H ZlvyMbNXsLZKFArnrw9ju6aExXoCx17Y0hkMPH1u7RGCB0Cc62fogB526OZs/bbPmngiuhAk gJbyuUjQzAz44kxuzsG9pkOUSUF/TF7BupG3K4e+RjxKjsdEe1ohsW8Eul+F0XIX1R0i84Jf hO6hVI2iywvEyjd2syEu7uvVBJJeQh5sYuAwLmixPISbS0OjGRiLlgPwejqJIkVElGQTQbLh N0CdHijKtMYYBkhEZjZ+0Mysw2kmRo28z6cdd7wmFpjt57L9Lw4qLP1KvkospnYN5+zBmwaB lHf6TxdkxGCuaviQ6N/PEcIwB3px2aTk/LmIE99vtiihH19PNhIgLXge7JR2tRFVLdfSqs47 YD1oDQY9ZO1h0FtcPKJKs0K5Ag0ETw4dRwEQAKqcD421qgwXKhpyrcb+eTA9UmTTOVTO9MzY cJ9RgACXE3GXdofkhVWzY7/aensghIpxYo+nmKGUS4eixGfPKiZDQPQFFRjBgvkPyKhoui9S x4/96c20+jTQiUlUX0eF5UpZtLBCW7CSPXdQamZbEltXL2Wit41KAP4cysQuvatTKYdVtao1 499lbsbHy5zqrdiV9NAdnPsqKzoKn5GyAEDYQS2OiB6yV2w94ezJUHxoE2zb/b5bHvP7DvqJ GU8vu207h4hgxu77hsByrgDRCazDnEHCYAs12pV3nrebzEVgfZsUvCVKnj+gvV7oFxM1II/8 AICSwcBDn6aGvQISNdzWPTwXdQQwGyur5SKtgnP0tX6DiBFe8xRqQnLBvOcu+E/WVWl3VKzp EHscEoLHCaDbqYPvpz93eFc1sueojnPXnjir6R/fyHlowBuKMcUQJdS5LXXUMAHQw8AdsYVA BjZfTXzGh1LOpEErT0fERtY7Vdi+VgKJWmt5boxxJNtjBMhSq1ZYR/UdMXG6C2Br5Jpl2aPu DwrcwT/HKZCeOKR+usNWQipxRXJ36o/HShc5Z6nWTOK20Txe6+jLzCIwsbhOreRw4SLxWoZS 450rUxIzlGxQ8LQaUl53NE8tQUsqx1LVPlABpqrXN5y8xFph0uNJyB7fzfSDdw9X3Sq8J3+1 ABEBAAGJAh8EGAECAAkFAk8OHUcCGwwACgkQcJRvFoB47VLNMxAAz6Yf92x6wuAgqoYyGNaP BLL9B3Y6LCsds184C3BxHCX4Tf7k7kRWBcWa/SJyNTzbLZBestxH/O28DtA+sdhFx8SOQykg Qx0u3VgRRLIgWRwDhAzCfD8Z9nDMGK4GKOqcHzH4GioQrajGXhKvPvECc8C9tbqkEVapayEa qteNCm1vPEC01+dwg5+xuzAUfsY3Y60wuAHmr+BwDHBrYjrURYsghqnDz9ajmZv4+1bjj7wh IVVPyMwgLCJWgv+Ni2H/s6BffS+NBLdXOxHq1QyKnlYOSHB0WXnBeq3TUAcpU4CejZi7nI6a sFTS7yi7t4rT4xnFiA0FduPoUaaG62Uin4f6XzjZxKLU8GlAuMWbepSXIL+6FQzOjlN/h9jS H9yS721C7O1vjiJJWaVR/oar/dzoxqwRJbz3hyMkg3+P+xFjD/kJ2BApi2ln2mvH0bq75mwV LS60M74u3ryiHGUDgDxO6dUfZ5paBia3+iW99Pfcf9HZtj+4FC861X5fsCwL3oXvEoToJWjX 3GbP7w/7XyYrxprQy+h8f21ouIgIRzNKDgdScCCepf/M9UdotysxW0zEYAv62ywCuSF+1lhU BfU8IvILfMe+rLmasTwsPBkHAJn/oo73R6dda2rkG8RTyLkrvDPbQYzZrYlzlg5TKLUXPPZr I3KbDCDuQHywEBQ=
User-Agent: Telnet/1.0 [tlh] (PDP11/DEC)
In-Reply-To: <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:15147

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qglVH7lZey3kReje2zUkiwACqlo49qHes
Content-Type: multipart/mixed; boundary="e30amjJkBEh4uavvum5RtF4WsbmPHWAcL";
 protected-headers="v1"
From: =?UTF-8?B?TMOpYSBHcmlz?= <lea.gris@noiraude.net>
To: chet.ramey@case.edu, bug-bash@gnu.org
Message-ID: <405e525c-278e-7779-3c39-3cf58d4bfa1a@noiraude.net>
Subject: Re: built-in printf %f parameter format depend on LC_NUMERIC
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>
 <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu>
In-Reply-To: <91ed1981-df04-aa06-b108-23c7f89de3b4@case.edu>

--e30amjJkBEh4uavvum5RtF4WsbmPHWAcL
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Le 12/07/2019 =C3=A0 21:16, Chet Ramey =C3=A9crivait=E2=80=AF:
> On 7/12/19 12:46 PM, L=C3=A9a Gris wrote:
>> Le 09/07/2019 =C3=A0 22:02, Chet Ramey =C3=A9crivait=E2=80=AF:
>>
>>> 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.
>=20
> 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. F=
or
> 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-conforma=
nt
> systems, those library functions generally honor the locale's decimal_p=
oint
> character as the radix character.
>=20
> The `bc' you're using isn't POSIX conformant.
>=20

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=20
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=20
locale, then I am almost fine with it. I can still set the locale to=20
match the bc script number formats. It would be quite annoying having a=20
bc script with numbers formatted to the da_DK locale that works only=20
with a POSIX compliant bc command and only on systems with the da_DK=20
locale available, but I am sure I can run any bc script that is using=20
numbers formatted to the POSIX locale if I switch the local to POSIX=20
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=20
LC_NUMERIC, because human beings will read these numbers rather than=20
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=20
printf to bridge POSIX locale formatted floating-point numbers to any=20
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,=20
is best done with POSIX locale formatted numbers.
lcnumconv can also help deal with human input of floating-point numbers=20
conversion to POSIX for processing these. Because Bash only know about=20
strings and internally about integers. The built-in read can not=20
translate floating point numbers to anything. It is just strings of=20
characters. In this regard, printf support for floating point numbers is =

an alien ^^.

--=20
L=C3=A9a Gris


--e30amjJkBEh4uavvum5RtF4WsbmPHWAcL--

--qglVH7lZey3kReje2zUkiwACqlo49qHes
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKpMeKD8gLuW/zE9wcJRvFoB47VIFAl0o5ckACgkQcJRvFoB4
7VKDdw//RjHc7Tc8CNgEyUdEECc/3p0pnd4s7oAqXBnbK2CS1ZSk47NOUoWQSCAq
+8GNzoyDCPXvAYPQkQI1xIOJRLpDVZ1AhXAvYtmRY1W3dDchl96LVTHZ3NBGmBEH
X6lkIta2wYhu1zWPSSrho7qpx+voKOx5I66SY9qJvIIWvNbItWQtUWd3AazDzKLz
b8jOrEqG+wXTmyrxYhgv+fSZgCRAVVugGYPpKD0dQkC6v0nT18tSsVJNG9AxVbYU
AO3oD2RzI19LJudbk0LCZxSeqaNMQHQAtEVM/iZwCJZbyvnLJbvz6U7yDyXerjRk
ZOA21JPLZjOMY6YiUY0pJDRG0icwG5X/oQdndB/YVH3EJIjY/Z3nxYunQXqPGfqc
6BUUV5praHymXbB9iywJNJJdD1c3c3i7c2Fnyp5sV6zEYhk64QwUGjBFs4opMF3O
/32gSQ5HGdk6L3R65RmCSMlS5lpfgS41RAApdoPoTGpkJOTaFWChbWLYLR5DrKWz
8Y6ZfNGvJ5OHFP6uqRN+FK0ba/gHmcWt/44EJHaKsHQCxeCNLu9l3mHBuq0JEwLp
Dlq9olk89W3JOMkYIJ2BazxcSYNxdpSLs6Cq207is9lOKp8YSGCycmXxNL8ZCHeZ
9R0My7UnsfpVzRe9NbWT++KsYzWBgoKjWo1Q2Q+CatYSdlLnRdc=
=bMXM
-----END PGP SIGNATURE-----

--qglVH7lZey3kReje2zUkiwACqlo49qHes--