Shell 逐行读取文件：为什么最后一行会漏掉？

批量处理文件清单时，有一种问题不容易被发现：前面的记录都正常，唯独最后一条没有执行。文件没有损坏，路径也没有写错，区别只是最后一行后面没有换行符。

学习 Shell 的逐行读取后，我用本地小样例核对了这个边界。它不仅影响下载清单，也会影响服务器列表、待处理路径和配置检查脚本。下面的代码面向 Bash 和普通文本文件，所有示例都可以在本地临时目录运行，不需要云资源。

先复现：两条内容，只处理了一条

用 printf 创建一个没有末尾换行的文件：

printf 'first\nsecond' > input.txt
while IFS= read -r line; do
  printf '<%s>\n' "$line"
done < input.txt

循环只会打印 <first>。这里的关键是，while 根据 read 的退出状态决定是否执行循环体，而不是根据变量是否拿到了字符。

读取 second 时，read 遇到了文件结束，返回非零状态。变量里虽然已经有 second，循环体却没有机会处理它。本机 Bash 的 help read 也明确说明，遇到文件结束会返回失败状态。

给最后一段内容一次处理机会

可以把条件写成：读取成功，或者读取失败后变量中仍有内容。

#!/usr/bin/env bash
set -eu
input=$1
while IFS= read -r line || [[ -n "$line" ]]; do
  printf '<%s>\n' "$line"
done < "$input"

保存为 demo.sh 后执行 bash demo.sh input.txt，两条记录都会输出。正常带末尾换行的文件同样适用；空文件不会凭空生成一条记录。

这里每个细节都有作用。IFS= 防止 read 按默认分隔规则去掉行首行尾的空白；-r 保留反斜杠，不把它当作转义符；"$line" 避免后续展开再次拆词；固定的 printf 格式串则让内容中的 %s、-n 按文本输出。

这段代码使用了 Bash 的 [[ ... ]]，请用 Bash 执行，不要默认交给任意 /bin/sh。

保留原文，和跳过无效记录，是两回事

如果清单中有一个空行，上面的代码会输出 <>。这不是多读了一条，而是保留了输入中真实存在的空行。

有些任务需要忽略空行，可以在循环体中增加：

[[ -z "$line" ]] && continue

但只包含空格的行并不等于空字符串。是否去掉空格、是否忽略注释，要按文件格式决定，不能在通用读取函数里随手处理。例如，文件名本身就可能包含空格。

另一个常见陷阱是改成 for line in $(cat input.txt)。命令替换与未加引号的展开会让文本重新拆词，带空格的记录不再是一整行，因此不适合用来替代逐行读取。

我实际验证了哪些边界

本地测试用精确输出对比覆盖了七种输入：空文件、正常末尾换行、末尾无换行、单独空行、首尾空格、反斜杠，以及包含 -n 和 %s 的普通文字。七项均通过。

测试过程中还有一个小教训：期望值本身也可能写错。把含反斜杠的路径放入 Bash 的 $'...' 字符串时，\t 和 \f 会被解释为控制字符。测试期望值改成普通单引号保存路径、单独拼接换行后，才与原始输入一致。排查失败用例时，需要同时检查程序和测试数据。

这份验证是本地 Bash 测试，不代表完成了云平台上的实操实验，也没有对生产服务器做任何修改。

使用范围要说清楚

这个循环适合约定好格式的普通文本清单，不是任意文件名或二进制数据的解析器。文件名可以包含换行，处理这类路径应使用以 NUL 分隔的专门流程。Windows 文本的 CRLF 也需要按输入约定处理，不能以为 read 已自动清理回车。

此外，循环体中的命令可能继续读取标准输入。如果要在里面调用交互式程序，应单独安排它的输入，避免它把后续清单吞掉。

真正值得保留的习惯是：写好正常路径后，再补一个没有末尾换行的输入。对批处理脚本来说，最后一条记录也应该和第一条一样被认真处理。