[bug #68453] bash 5.3 on macOS (Homebrew): inconsistent locale handling e.g. in printf builtin

--8323329-846930886-1781696967=:1536169
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

URL:=0A  <https://savannah.gnu.org/bugs/?68453>=0A=0A                 Summa=
ry: bash 5.3 on macOS (Homebrew): inconsistent locale=0Ahandling e.g. in pr=
intf builtin=0A                   Group: The GNU Bourne-Again SHell=0A     =
          Submitter: None=0A               Submitted: Wed 17 Jun 2026 11:49=
:24 AM UTC=0A                Category: None=0A                Severity: 3 -=
 Normal=0A                Priority: 5 - Normal=0A              Item Group: =
None=0A                  Status: None=0A                 Privacy: Public=0A=
             Assigned to: None=0A             Open/Closed: Open=0A         =
Discussion Lock: Unlocked=0A=0A=0A    _____________________________________=
__________________=0A=0AFollow-up Comments:=0A=0A=0A-----------------------=
--------------------------------=0ADate: Wed 17 Jun 2026 11:49:24 AM UTC By=
: Anonymous=0AOn macOS, bash 5.3 installed via Homebrew shows inconsistent =
behaviour e.g.in=0Athe printf builtin when handling floating-point formatti=
ng under=0ALC_NUMERIC=3DC.=0A=0AIn an interactive shell, numeric input usin=
g dot decimal separator is rejected=0Aas invalid, and output uses a comma d=
ecimal separator, despite locale=0Avariables being unset or set to "C".=0A=
=0AThe issue is reproducible only in Homebrew bash 5.3 and does not occur i=
n the=0Asystem default very old bash (3.2), nor was present in bash 5.2.=0A=
=0ASteps to reproduce:=0A=0A1. Start Homebrew bash 5.3: /opt/homebrew/bin/b=
ash=0A2. Ensure no locale variables are set: env | grep '^LC_\|^LANG'=0A3. =
Run: printf "%f\n" 1.234=0A=0AActual result:=0A=0A=0Abash: printf: 1.234: i=
nvalid number=0A1,000000=0A=0A=0AExpected result:=0A=0A=0A1.234000=0A=0A=0A=
=3D=3D=3D Additional observations: =3D=3D=3D=0A=0A* System bash works corre=
ctly:=0A=0A=0A$ /bin/bash --norc --noprofile -c 'printf "%f\n" 1.23'=0A1.23=
0000=0A=0A=0A* Fix observed with explicit locale:=0A=0A=0A$ LC_NUMERIC=3DC =
bash -c 'printf "%f\n" 0.123'=0A0.123000=0A=0A=0A* Python confirms correct =
libc locale state: decimal_point =3D=3D "."=0A=0A* locale command reports L=
C_NUMERIC=3D"C" even when issue is present.=0A=0A* The most surprising beha=
viour is that running bash locally setting=0ALC_NUMERIC fixes the behaviour=
 of the present session:=0A=0A  $ printf "%f\n" 1.23=0A  -bash: printf: 1.2=
3: invalid number=0A  1,000000=0A  $ LC_NUMERIC=3DC bash -c 'printf "%f\n" =
0.123'=0A  0.123000=0A  $ printf "%f\n" 1.23=0A  1.230000=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A    _____________________________________________________=
__=0A=0AReply to this item at:=0A=0A  <https://savannah.gnu.org/bugs/?68453=
>=0A=0A_______________________________________________=0AMessage sent via S=
avannah=0Ahttps://savannah.gnu.org/=0A
--8323329-846930886-1781696967=:1536169
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCajKJxwAKCRCqLAuaBUf3
Ts8oAP9/BTBcuG1BVGZGB8A3bhoTMt2jG/P1WE89V4QULUEjiwEA0keKEePlNE4i
B9zDd/Ydde2M+KyyvCvnXv2clemHWgs=
=3+gU
-----END PGP SIGNATURE-----

--8323329-846930886-1781696967=:1536169--