管道pipe是 bash 里最常用的数据传递方式一句grep error app.log | wc -l就能把错误日志统计出来几乎所有踩过命令行的人都被这种“一个命令的输出塞给另一个命令”的效率打动过。可一旦牵扯到“多条命令”很多人就卡住了我想让管道左侧先跑几条命令再一起交给下游或者让管道右侧对每一行输入执行好几条命令总不能全部拆成单独管道吧这篇文章就把“管道中执行多条命令”的几种标准姿势讲透顺带说说我在实际写脚本时踩过的坑。适合正在学 bash 的中级用户也适合想把 shell 脚本写得更稳的老手。1. 先搞清楚管道到底在传递什么1.1 管道的本质是文件描述符的转发很多人把管道理解成“把前一个命令的文本结果复制给后一个命令”这个理解方向没有错但不够准确。真正建立管道的操作是把左侧进程的标准输出stdout接到右侧进程的标准输入stdin中间是一个内核缓冲区数据以字节流的方式流动。比如echo a | grep a运行的时候echo 往缓冲区里写了一个a加换行grep 从缓冲区里读出来做匹配两边是并发运行的不是 echo 跑完退出之后 grep 才开始。理解这一点很重要因为它决定了“让管道执行多条命令”到底在解决什么问题。如果你的左侧要跑多条命令你得让这些命令的输出按顺序合并到同一个 stdout 中最后统一作为右侧的输入如果你的右侧要跑多条命令你得让右侧的进程从 stdin 逐段读取数据并对每段数据执行一串操作。换言之问题从来不是“能不能把命令串在一起”而是“怎么让一组命令在一段管道中共享输入或输出”。可以做个最简单的实验echo hello | od -c。用od -c看字节你能明确看到管道另一侧读到的是完整的h e l l o \n而不是一串命令行的历史记录。管道两边都不是操作者在键盘面前而是两个进程在对接文件描述符。这个视角一旦建立后面所有分组、子 shell、while 循环的用法都会顺理成章。1.2 分号、、|| 和管道不是一回事“多条命令”这个概念本身并不新鲜cmd1; cmd2、cmd1 cmd2、cmd1 || cmd2都能在一个命令行里放多个命令。但它们都和数据流转无关只是控制命令何时执行。cmd1; cmd2不管 cmd1 成功还是失败cmd2 都会执行。cmd1 cmd2只有 cmd1 返回状态 0成功时cmd2 才会执行。cmd1 || cmd2只有 cmd1 返回非 0失败时cmd2 才会执行。cmd1 | cmd2cmd1 和 cmd2 同时跑cmd1 的输出流进 cmd2 的输入。所以写echo 1; echo 2会输出1和2但写echo 1 | echo 2只会输出2。原因就是echo 2根本不从 stdin 读数据管道对它的数值没有任何影响。我在帮同事 review 脚本时见过不少这种混淆本意是“执行完命令 A 再执行命令 B然后一起处理结果”结果写成A; B | C最后发现 A 根本没进入管道C 只收到了 B 的输出。问题就出在管道的优先级高于分号的语义上。1.3 问题到底出在哪管道的“两侧”都可以是一组命令一条管道有一个左侧和一个右侧但“命令”不一定只能是一个外部程序。bash 语法里允许把一组命令组合成一个整体出现在管道的任意一侧。你可以用花括号{ ...; }把一个命令序列包起来也可以用括号( ... )开启子 shell 包起来还可以定义一个函数把一组命令藏在函数名后面。右侧也一样while read ...; do ...; done本身就是一个复合命令可以整体放在管道右侧。所以“管道执行多条命令”在 bash 里并不是什么黑魔法只是组合命令的用法。接下来的章节我会把左侧、右侧、以及左右都有多条命令的情况分开讲每块都给出可以直接用的写法。2. 管道左侧执行多条命令合并输出再交给下游2.1 用花括号分组让多条命令共用一个 stdout最直接的多条命令进管道左侧的写法是用花括号把命令序列包起来比如{ echo 开始处理; date %s; echo 处理结束; } | while read line; do echo 收到: $line done这段脚本里花括号内的三条命令会按顺序执行它们的 stdout 全部合并到同一条管道里。while 循环会依次收到三行开始处理、时间戳、处理结束。整个过程非常像一个自定义命令集合临时变成了管道左端的生产者。注意花括号的语法细节左花括号{后面必须有一个空格右花括号}之前必须有分号或者换行。写成{echo a; echo b;}会直接报语法错误。原因是 bash 把{当成保留字而不是普通的命令名保留字后面必须用空白分隔}必须单独出现在命令边界上。这个规则不算直观但只要记住“左括号后空格右括号前分号”就不会踩坑。另外花括号分组是在当前 shell 进程里执行的。分组内如果做了cd /tmp或者给变量赋值结束之后当前 shell 依然保留这些修改。这有时是优点有时是坑。如果你想临时改变环境又不影响当前会话就换成括号子 shell。2.2 用子shell括号隔离环境又能跑多条命令管道左侧需要跑多条命令同时不希望这些命令的副作用污染当前 shell 时用括号子 shell 是最顺手的方案(cd /tmp; ls; pwd) | head -3括号里的三条命令在一个子 shell 中执行。子 shell 是当前 shell 的一个子进程它继承了变量、环境变量和当前工作目录但它内部做的任何修改都不会传回父 shell。上面的命令无论括号内pwd输出什么外面的当前目录都不会变。如果你在脚本里需要临时切到一个目录做点统计又不希望脚本后面的路径跟着漂移这个写法非常实用。括号子 shell 的语法宽容一些(cmd1; cmd2; cmd3)里不强制要求前后加空格;也可以用换行代替。不过为了代码风格统一我会习惯写成( cd /tmp; ls; pwd )这种留有空格的形式看起来清晰也减少误判。子 shell 里面不仅可以顺序执行命令还可以写if、for等复合结构所以它本质上是一个完整的小型脚本环境只是所有输出最终被管道右侧消费。如果需要临时设一个环境变量括号也很有用比如( export LANGC; locale ) | grep -i time可以在不影响当前 shell 语言环境的前提下跑一条locale命令。变量隔离是子 shell 的核心价值。2.3 用函数封装复用和阅读都更有利如果左侧的多条命令不止用一次或者逻辑太长放在管道里会非常臃肿。这时候定义一个函数就好很多prepare_summary() { echo $1 ls -ld $1 stat -c %s bytes $1 } prepare_summary /etc/hosts | head函数体内可以写任意多的命令最后所有输出合并成一条流交给函数调用处的管道。函数还可以接收参数就像外部命令一样调用方不会看到内部细节。上面这个函数的三条命令都是为同一个参数服务的打印标题、列出权限、显示文件大小。比起在管道里写一大串花括号分组函数的最大优势是可复用。同一个函数可以出现在多条不同的管道左侧需要调整时只改函数定义。而且函数默认在当前 shell 执行和花括号分组一样共享变量如果你希望函数里做的修改不外泄可以在函数体内部用local声明局部变量或者改成在括号子 shell 里调用函数比如( prepare_summary /etc/hosts ) | head。实战中我更推荐把“产生数据”的逻辑抽成小函数让管道看起来像英文句子一样容易读。3. 管道右侧执行多条命令让下游逐行处理输入3.1 while read 循环逐行消费并执行多条命令如果左侧已经有一批数据你想对每一行都做多次处理最常见的写法是用while read把管道右侧变成一个逐行处理循环seq 3 | while read n; do echo 当前数字: $n double$((n * 2)) echo 它的两倍: $double done管道右侧的while read ...; do ...; done是一个复合命令它每从 stdin 读一行就会依次执行循环体里的所有命令。换句话说你不必为了“对每一行执行多条后处理”去写一个 Perl、Python 脚本bash 自身就能做到。循环体里可以放任意多的命令还可以嵌套 if、case、for自由度非常高。处理日志时我建议把读取方式写严格一点while IFS read -r line; do ...; done。IFS可以禁止 read 自动去掉行首尾的空白-r可以防止反斜杠被当成转义字符。默认的 read 行为会把不完整信息吞掉尤其在处理路径、用户输入这类数据时很容易出问题。如果你确实需要把一行拆成多个字段比如统计结果里的“次数 IP”那就不设IFS直接read count ip它会用空白作为分隔符剩下的内容全部归入最后一个变量。这里有一个必须知道的坑管道右侧的while几乎总是在子 shell 里执行。你在循环里赋值的变量循环结束后在外的 shell 里根本看不见。比如total0 seq 3 | while read n; do total$((total n)) done echo total$total # 输出 total0原因就是seq 3 | while ...这个管道让右侧的 while 在一个子进程里跑total的累加只发生在子进程的变量副本里。如果你需要循环结束后继续使用计算结果最简单的办法是改用“进程替换”把管道左侧变成伪文件给 while 使用让 while 留在当前 shell 执行。这个技巧在本章实战案例里会专门演示。3.2 xargs bash -c每条输入跑一组子命令while read适合逐行处理但它有一个限制它是在一个循环里持续读数据不太适合对每条输入单独起一个整洁的“任务边界”。另一个选择是用xargs配合bash -c让每个输入项都在一个全新的 bash 进程中执行多条命令。find . -name *.log -print0 | xargs -0 -I {} bash -c echo 处理文件: $1 wc -l $1 echo 完成: $1 _ {}这条命令里的关键点是bash -c后面的参数顺序bash -c 脚本内容 第0个参数 第1个参数 第2个参数...。bash 脚本内部$0会被赋成第一个参数$1是第二个参数。所以_ {}中的_是给$0占位用的真正传入的文件路径{}会变成脚本内的$1。如果漏掉_路径会被当成$0脚本内部全部$1都是空的这个 bug 很容易出现且很难一眼看出来。外层脚本字符串我通常用单引号这样$1不会在父层 bash 里被提前展开而是进入子层 bash 后再取值。如果你需要传环境变量可以在bash -c的脚本里读取已经 export 的环境变量或者用命令替换构造参数。这种方式很适合“每个输入文件都要打包、压缩、记录日志”这类组合操作脚本内容就是一段小逻辑用分号或换行隔开多条命令都行。xargs还支持-P 4这类并行参数可以让多个 bash 子进程同时跑。执行效率高但要注意下游命令的幂等性。如果多个进程都往同一个文件追加内容行序会不可控如果都在写同一个临时文件可能互相覆盖。并发不是免费午餐控制好副作用比跑得更快更重要。3.3 tee 进程替换同一份数据分发给多个下游有些场景不是“对一行处理多次”而是“把同一份数据同时送给两个不同的下游命令”。这时 tee 配合 bash 的进程替换(...)非常好用ps aux | tee (grep ssh ssh_proc.txt) (grep mysql mysql_proc.txt) /dev/null(grep ssh ssh_proc.txt)在 bash 里会被视为一个文件描述符路径往这个路径写入的内容会直接进入grep ssh的 stdin。tee 默认会把自己读取到的数据同时输出到所有参数指定的位置两个进程替换各拿到一份再通过/dev/null把 tee 原本的 stdout 丢弃终端就不会被刷屏。于是你能用一条命令从同一份ps aux输出里分别筛出 ssh 相关进程和 mysql 相关进程各写各的文件。进程替换里的命令不一定只有一个也可以是一个分组。比如( { grep ssh; echo ssh 筛选完成; } ssh_proc.txt )这样下游能为同一个数据源执行多条后续命令。不过进程替换里的命令是异步运行的和主管道并行执行如果后续步骤依赖文件已经写完你最好先确认文件内容落盘或者用 wait 等待相应进程结束否则可能拿到空文件。这个细节在批量处理文件时尤其重要。实现“同一份数据多路分发”还有另一种思路先把数据存到临时文件再分别用两条管道处理。但进程替换的优势是省掉中间文件数据流一旦起来就不落地适合不想污染磁盘的场景。bash 支持sh 不支持所以脚本头最好写成#!/bin/bash。4. 组合使用前的关键细节与避坑4.1 管道退出码会被谁掩盖pipefail管道默认的退出状态是右侧最后一个命令的退出状态。这意味着左侧命令即使失败你也根本察觉不到false | true echo $? # 输出 0false明明失败了最后一条命令true成功所以管道的退出码是 0。一旦你在管道左侧跑了多条命令这个问题就被放大了左侧某条关键命令写文件失败右侧却可能继续正常输出结果脚本整体也报成功最后你排查半天才找到是生产命令悄悄失败。解决办法是在脚本开头设置set -o pipefail。这个开关会让管道返回最后一个非零退出码而不是无条件采用最后一条命令的状态。加上它之后false | true的退出码就是 1。再配合set -e脚本遇到失败管道会直接跳出不会带着隐患继续执行。我写稍微复杂一点的脚本时习惯在文件开头放一行set -euo pipefail。-u让未定义变量直接报错-e让命令失败时退出pipefail弥补管道退出码的盲区。这三个选项组合起来多命令管道的可靠性会高很多。唯一要注意的是pipefail不是 POSIX sh 的标准功能所以这类脚本必须用#!/bin/bash而不是#!/bin/sh。4.2 分组语法细节花括号空格和分号花括号分组最容易被语法错误卡住。正确示例是{ echo a; echo b; } | grep a错误示例是{echo a; echo b;} | grep a第一个问题在于{被识别为保留字后面必须跟空格第二个问题在于}前必须有一个分号或换行因为 bash 需要知道命令序列在哪里结束。括号子 shell 对这点的容忍度更高(echo a; echo b)通常不会报错。但花括号分组的好处是它不额外拉起子进程性能和变量可见性都更可控所以该用还是要用只是要接受它的语法规则。另一个常见误区是把管道写在分组内部。{ echo a | grep a; echo b; } | sort中管道是echo a和grep a之间的局部管道分组总输出仍然会被后面总的sort处理。要分清局部管道和整体管道的边界。我在 review 时经常提醒同事写复杂管道前先在纸上圈出“哪些命令是分组内的小管道哪些是分组外的大管道”这样就不会搞混数据流向。4.3 stdin 被吞与 SIGPIPE 的问题管道右侧多命令处理时要留意某些命令会“吞掉” stdin导致输入提前耗尽。最典型的例子是在 while 循环里调用 sshprintf host1\nhost2\nhost3\n | while read host; do ssh $host who donessh 默认会读取当前进程的 stdin把管道里剩余的 host2、host3 全部当成自己的输入于是循环只处理一次就结束了。解决办法是给 ssh 加-n参数或者把 /dev/null重定向到 ssh 命令后面保证它不去读循环的 stdin。类似的命令还有read、cat、sudo等凡是可能消费 stdin 的程序在管道右端循环里都要警惕。还有一类问题是 SIGPIPE。当右侧命令提前退出比如yes | head -1左侧的yes还在不断写数据但管道读取端已经关闭yes会收到 SIGPIPE 信号直接终止。这是正常行为。但在多命令分组中如果左侧某条生产者命令因为 broken pipe 被终止整个管道的退出码在pipefail打开时会变成非零。这不一定是逻辑错误只是管道被人为截断了。知道这一点排查脚本时就不会被奇怪的 141 退出码吓到。5. 实战案例日志统计管线的完整改造5.1 原始需求与第一次实现假设app.log每行以客户端 IP 开头形如203.0.113.5 GET /api/users。需求有三点统计访问量最高的 20 个 IP把统计结果写入top_ip.txt对于访问量超过 100 的 IP往标准错误输出一条告警。第一次实现往往只覆盖第一点awk {print $1} app.log | sort | uniq -c | sort -rn | head -20这条管道很经典awk 提取第一列 IPsort 排序uniq -c 统计次数再按次数倒序head 取前 20。问题也很明显它只是把结果打到终端没法在得到每一行结果的同时执行额外命令也没法在脚本中感知管道某个环节失败。5.2 改成管道右侧的多命令版本利用 while 循环把“写文件”和“告警”塞进管道右侧#!/bin/bash set -o pipefail awk {print $1} app.log | sort | uniq -c | sort -rn | head -20 | while read count ip; do echo 访问量: $count IP: $ip printf %s %s\n $count $ip top_ip.txt if (( count 100 )); then echo [告警] $ip 访问量超过阈值: $count 2 fi done管道右侧的while read count ip用空白分隔读取每行uniq -c输出的行首是次数后面是 IP正好映射到count和ip。循环体里先打印一行结果然后以追加方式写入文件再用算术判断(( count 100 ))检查阈值。这样一条管道就同时完成了统计、落盘和告警三件事。开头加的两个 bash 选项很有用。set -o pipefail保证如果 awk 读取日志失败、sort 崩溃或 uniq 出错整条管道都会返回非零退出码而不是被最后的 while 成功状态掩盖。对这个多命令组合场景来说管道越长中间环节的故障越容易藏起来pipefail 越值得开。5.3 变量带出循环用进程替换代替管道如果你还想在循环结束后汇总 top20 的总访问量上面的管道写法就有问题了while 在子 shell 里执行循环内累加的变量在外部看不到。这时可以用 bash 进程替换#!/bin/bash set -o pipefail total0 while read count ip; do total$((total count)) printf %s %s\n $count $ip top_ip.txt if (( count 100 )); then echo [告警] $ip 访问量超过阈值: $count 2 fi done (awk {print $1} app.log | sort | uniq -c | sort -rn | head -20) echo top20 总访问量: $total注意最后的done (...)( ... )是一个进程替换它会把自己内部的输出包装成一个类似临时文件的路径再通过输入重定向交给 while。这样一来while 循环不再处于管道右侧的子 shell 里而是在当前 shell 中执行循环里修改的total在循环结束后依然有效。整条统计管道仍然在进程替换内部数据流向没有变。这个写法是 bash 特有的但它解决了 while 循环最让人头疼的“变量带不出来”问题。如果你在 sh 环境下跑会看到语法错误所以脚本声明一定要是 bash。实际工作中我在需要“循环后还要用计算结果”的脚本里几乎都会优先考虑这个结构。5.4 抽取左侧多命令函数化改造如果左侧的预处理步骤变多比如要先过滤出 HTTP 请求、再提取 IP、再合并多个日志文件直接写在管道里会越来越难看。这时候把左侧逻辑抽成函数prepare_ip() { grep -E HTTP $1 | awk {print $1} } prepare_ip app.log | sort | uniq -c | sort -rn | head -20函数内部包含了一条局部管道grep 先过滤行awk 再提取 IP函数整体的输出就是最终 IP 列表。外部再通过一条正规管道做统计。这样左侧的多条命令被折叠成一个语义清晰的prepare_ip想看细节就去看函数定义调用处只关心“把 app.log 变成 IP 列表”。函数还能接多个参数比如同时处理多个日志文件你可以用循环在函数内遍历参数把多次结果合并输出。左侧命令越复杂函数化收益越明显。我自己的标准是管道本身超过 5 个环节或者某一段分组超过 3 条命令时就开始抽函数或者变量别让一个命令行长到没有人愿意读。6. 速查表和个人建议6.1 常见场景速查表场景推荐做法备注管道左侧执行多条命令用花括号分组或括号子 shell当前 shell 还是子 shell取决于是否需要隔离变量管道右侧逐行处理多行用 while read 循环循环体里可以放任意多命令每条输入都需要一组独立处理用 xargs 配合 bash -c注意bash -c的$0占位参数同一份数据分发给多个下游用 tee 加进程替换适合同时生成多个结果文件循环结果要保留到当前 shell用进程替换代替管道while 在主 shell 中执行整条管道任一环节失败都要发现设置set -o pipefail最好配合set -euo pipefail使用这张表基本上覆盖了我日常遇到的多命令管道场景。拿不准用哪种写法时先对号入座看一眼再根据是否需要变量隔离做最终选择。6.2 几条我的实操建议第一写之前先问自己两个问题左侧到底产生了什么 stdout右侧到底要从 stdin 里得到什么把这两个问题的答案写清楚剩下的就是选组合语法。第二不要为了“多条命令”而强行使用进程替换或 xargs。如果只是要在管道左侧按顺序执行三次输出花括号分组就够了如果只是逐行处理while read 是最直接的。工具越简单越不容易出错。第三bash -c的引号嵌套越少越好。脚本内需要传参时优先用bash -c ... _ 参数的方式外层用单引号包住脚本避免变量在错误的时机被展开。脚本内容再长一点就直接写一个临时脚本文件而不是在 xargs 参数里堆一屏命令。第四本地调试时别害羞多用bash -x script.sh看执行过程或者用 shellcheck 做静态检查。多命令管道的小问题往往不是逻辑错而是某个分号、空格或引号写错静态检查工具能减少大量低级失误。第五并发场景要格外警惕副作用。xargs -P和进程替换都会让后台命令同时执行如果它们都往同一个文件追加内容结果可能是乱序的如果都写同一个临时文件可能互相覆盖。让每个下游使用独立的结果文件或者用 append 模式写日志能省不少麻烦。我个人做复杂日志管道时习惯先把需求写成一串普通命令跑通之后再逐步抽出函数、调整子 shell 和进程替换。管道本身只是水渠你可以把左侧的多个源头接在一起也可以在右侧放一个闸门逐段处理只要想清楚哪段是产生流、哪段是消费流多命令并不会带来混乱。最后再提醒一句遇到“命令写好了但结果不对”的诡异问题时先把IFS read -r和set -o pipefail这两件小事检查一遍它们解决的往往是最容易被忽略的大问题。