关于bash 3.2.25中printf命令随LANG环境变量异常表现的问询

这是一个典型的bash版本兼容性问题，核心在于不同版本对locale变量的 fallback 逻辑不一样。先看你的测试脚本和不同环境的表现：

测试脚本 #

#!/bin/bash
echo before: LANG=$LANG LC_NUMERIC=$LC_NUMERIC
unset LANG LC_NUMERIC
echo after: LANG=$LANG LC_NUMERIC=$LC_NUMERIC
printf "%f\n" .34

不同环境的运行结果 #

RHEL 6（bash 4.1.2）——符合预期 #

before: LANG=es_ES.UTF-8 LC_NUMERIC=
after: LANG= LC_NUMERIC=
0.340000

RHEL 5（bash 3.2.25）——异常报错 #

printf: .34: invalid number
0,000000

问题原因 #

bash 3.2和bash 4.x在处理LANG/LC_NUMERIC变量被unset后的行为有明显差异：

• bash 4.1.2+：当这些locale变量被unset后，会自动 fallback 到C locale（POSIX标准locale），此时小数点分隔符是点号（.），所以printf能正确解析.34。
• bash 3.2：即使unset了这些变量，bash依然会保留系统默认的locale规则（比如你之前的es_ES.UTF-8中用逗号,作为小数点分隔符），不会自动切换到C locale，因此printf会把.当成无效字符，抛出错误。

解决办法 #

不要依赖unset来重置locale，而是显式设置需要的locale。比如要让printf使用点号作为小数点，直接设置LC_NUMERIC=C即可：

修改后的脚本：

#!/bin/bash
echo before: LANG=$LANG LC_NUMERIC=$LC_NUMERIC
# 显式设置为C locale，确保numeric格式符合POSIX标准
export LC_NUMERIC=C
echo after: LANG=$LANG LC_NUMERIC=$LC_NUMERIC
printf "%f\n" .34

这样不管在bash 3.2还是4.x版本中，都会输出正确的0.340000。

内容的提问来源于stack exchange，提问作者Jdamian