Bash读取含小数文件计数器时嵌套for循环异常排查

嗨，我来帮你拆解这个问题，顺便聊聊更稳妥的脚本写法～

一、问题根源：DOS换行符（CRLF） #

你遇到的“前几次输出异常，最后一次正常”的情况，大概率是因为你的f.txt和l.txt是用Windows系统保存的，带了DOS风格的换行符（\r\n），而Bash默认识别的是Unix风格换行符（\n）。

当你用$(<f.txt)读取文件内容时，Bash会把所有内容按空白（空格、换行、制表符）分割成一个个“单词”，但每个数字后面的\r（回车符）会被保留下来。比如第一个变量$f实际是25\r，当你执行echo "$f $l"时，\r会让光标跳回到行首，后面的$l就会把25给覆盖掉，看起来就成了“ 0”“ 0.5”这种格式；而最后一个数字后面没有\r，所以输出正常。

解决办法 #

把文件转换成Unix风格换行符就行：

• 用dos2unix工具直接转换：

  dos2unix f.txt l.txt
  

• 如果没有dos2unix，用sed去掉末尾的\r：

  sed -i 's/\r$//' f.txt l.txt
  

处理后再运行脚本，就能得到你预期的25 0、25 0.5这类输出了。

二、为什么要避免用for循环读取文件内容？ #

chepner的建议非常中肯——永远不要用for f in $(<file)这种方式读取文件，原因有这几个：

1. 空白符处理不可控：Bash会把文件里的所有空白（空格、换行、制表符）都当作分隔符，如果你的文件里有带空格的内容（比如“hello world”），会被拆成两个独立的变量，完全不符合预期。
2. 特殊字符会出问题：如果文件里有*、?这类通配符，Bash会自动展开成文件名，导致脚本逻辑混乱。
3. 大文件内存压力大：$(<file)会把整个文件内容一次性读到内存里，如果文件很大，会占用大量内存，影响脚本性能。

更稳妥的替代写法 #

针对你的场景（两个文件都是一行空格分隔的数字），推荐先把文件内容读到数组里再循环，这样既安全又清晰：

# 读取f.txt的所有数字到数组fs（-r避免转义，-a表示存入数组）
read -ra fs < f.txt
# 读取l.txt的所有数字到数组ls
read -ra ls < l.txt

# 嵌套循环遍历两个数组
for f in "${fs[@]}"
do
  for l in "${ls[@]}"
  do
    echo "$f $l"
  done
done
read -p "Press [enter] to continue..."

如果你的文件是每行一个数字的格式，那用while read的写法更合适（这是读取文件的标准最佳实践）：

# 外层循环读取f.txt的每一行，IFS=保留行首空格，-r禁止转义
while IFS= read -r f
do
  # 内层循环读取l.txt的每一行
  while IFS= read -r l
  do
    echo "$f $l"
  done < l.txt
done < f.txt
read -p "Press [enter] to continue..."

这里的IFS=是为了保留行首/行尾的空格，-r是防止Bash把反斜杠当作转义字符，能最大程度保证读取内容的准确性。

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