Bash 管道后的 while read 循环结束后，计数变量仍为 0

循环里打印的计数依次增加，循环后的总数却仍然是初始值。例如，下面的 Bash 脚本把三行文本送给 while read：

#!/usr/bin/env bash
count=0

printf '%s\n' alpha beta gamma |
while IFS= read -r line; do
    count=$((count + 1))
    printf 'inside=%s\n' "$count"
done

printf 'total=%s\n' "$count"

在未启用 lastpipe 的通常配置下，循环内应依次显示 inside=1、inside=2、inside=3，最后却是 total=0。这说明循环确实读到了输入，也完成了加法；需要检查的是赋值发生在哪个执行环境。

本文针对 Bash 的管道与子 shell 行为。其他 shell 的管道实现可能不同，不能仅凭终端外观判断。后面的进程替换写法也不是可直接交给所有 /bin/sh 的语法。

管道右侧修改了自己的变量副本

Bash 通常把多命令管道中的各个部分放进独立的子 shell。这里右侧的整个 while 是管道的一部分：它取得初始的 count=0，随后在自己的环境里把值加到 3。管道结束后，外层脚本继续使用自己的 count，这个值一直是 0。

把末尾输出接成 done && printf ... 不能传回变量。&& 决定后续命令是否执行，不会合并两个执行环境。把变量声明为 export count 也不能让子进程反向改写父进程的变量。

对照实际脚本时，先找 while 前面的 |。如果循环内已有完整的逐行输出，而外层值没有变化，这条执行边界就值得检查。如果循环内一次都没有输出，则还要检查输入是否为空、读取路径及条件，不能直接断定是变量作用域问题。

Bash 的 lastpipe 是一个例外：启用它且作业控制未开启时，管道最后一部分可以在当前 shell 执行。不要把某个已改过选项的终端中得到的结果，推广为所有 Bash 脚本的行为。下面两种改法让输入连接方式直接体现在代码中，无需依赖这个选项。

输入本来就是文件，重定向整个循环

不要先把文件送进管道再交给循环。把文件放到 done 后的输入重定向中，循环就可以留在当前脚本环境里。

下面假设已有 records.txt，内容是一行一条的普通文本记录，每行都以换行结束；文件名是示例路径，需按实际位置调整：

#!/usr/bin/env bash
input='./records.txt'
count=0

while IFS= read -r line; do
    count=$((count + 1))
    printf 'record=%s\n' "$line"
done < "$input"

printf 'total=%s\n' "$count"

< "$input" 作用于整个循环，read 每次从同一个输入流继续读取。循环中的赋值与末尾的输出处在同一环境，因此末尾能使用累加后的值。

IFS= 避免按默认空白分隔输入，-r 让反斜杠保留为普通字符。这两个选项用于保持文本内容，不负责改变管道的执行环境。例子会把空行也计为一条记录；如果业务要跳过空行，应明确增加相应条件，并按过滤后的记录数验收。

这份最小示例要求末行有换行。若文件最后一段没有换行，read 在遇到文件末尾时会返回失败，单纯以它作为循环条件可能漏掉那段内容。应先统一输入格式或另外处理末尾残行，不要把少一条记录与“总数仍为 0”混为同一故障。

输入来自命令，使用进程替换

需要边生成输出边处理时，可以把输出命令放进 <(...)，再把这个输入接到循环：

#!/usr/bin/env bash
count=0

while IFS= read -r line; do
    count=$((count + 1))
    printf 'inside=%s record=%s\n' "$count" "$line"
done < <(printf '%s\n' alpha beta gamma)

printf 'total=%s\n' "$count"

这个例子只使用固定的三行文本。按语法推导，末尾应显示 total=3；换成真实命令前，先用这种无业务副作用的输入核对循环结构。

done < <(...) 中，前一个 < 是输入重定向，后面的 <(...) 是进程替换，两者之间保留空格。进程替换内部的 < 与 ( 必须连在一起，不能写成 < (...)；两个小于号也不能合成 <<，后者属于另一种输入语法。

生成文本的命令仍在异步执行的独立进程中。改变的是消费者的位置：while 不再位于管道右侧，它的变量可以被后续代码继续使用。相反，若在 <(...) 内部给变量赋值，该值仍不会因此回到外层。

此写法需要 Bash，以及系统提供命名管道或 /dev/fd 支持。保存为 count-records.sh 后，应由 Bash 解释：

bash ./count-records.sh

文件名是示例。不要用 sh ./count-records.sh 运行含进程替换的脚本；显式指定 sh 时，脚本第一行的 Bash 声明不会替你选择解释器。

保留错误处理，再确认总数

从管道改成进程替换时，还要复核上游命令的失败路径。进程替换中的命令异步运行，循环正常结束不能单独证明生成命令成功；原来围绕管道设置的 pipefail 检查也不能原样充当这个异步命令的状态检查。

如果业务要求“生成失败就绝不处理”，可以先用原有的受控导出流程生成文件，明确检查生成命令的退出状态，成功后再采用文件重定向方案。不要把失败时只生成了一部分的文件当作完整输入，也不要用固定的公共临时文件名传递敏感记录。

验证时分别核对循环内处理的记录和循环后的总数。三行固定输入应得到三次内部输出及 total=3；空输入应保持 0。记录数正确之后，再恢复业务处理逻辑。不要用删除、更新数据库或批量远程操作来验证计数器。

修改前保留脚本副本，回退时恢复输入连接方式与原有错误检查。脚本回退只恢复代码，不会撤销循环已经执行的业务操作。如果真实目标是遍历文件名，不要把 ls 的显示结果当作通用记录格式，文件名可能含换行，隐藏文件的范围也需要单独定义。