带trap的Shell函数输出经管道传输时trap失效的原因探究

哈哈，这个坑我踩过！核心问题出在Shell处理管道的子进程机制上，咱们一步步拆解：

先看你的代码与现象 #

你的测试代码是这样的：

#!/bin/bash
cleanup () {
    echo "====> Calling cleanup"
}
_main () {
    echo "Starting"
    trap 'cleanup' 0
    echo "Completed"
}
_main | cat

带管道的运行结果（sh -x tp.sh） #

+ _main
+ echo Starting
+ trap cleanup 0
+ echo Completed
+ cat
Starting
Completed

完全看不到cleanup的输出。

不带管道的运行结果 #

$ sh -x tp.sh
+ _main
+ echo Starting
Starting
+ trap cleanup 0
+ echo Completed
Completed
+ cleanup
+ echo '====> Calling cleanup'
====> Calling cleanup

cleanup正常触发。

核心原因：管道创建子Shell，输出被管道机制“吃掉” #

当你使用_main | cat时，Shell会为管道两侧的命令分别创建独立的子进程：

• _main在一个子Shell里执行
• cat在另一个子Shell里执行

trap 'cleanup' 0是给_main所在的子Shell设置“正常退出时触发的陷阱”——这个陷阱其实是触发了的！只是你看不到输出，原因是：

1. _main的所有标准输出（包括cleanup的echo）都会被管道传递给cat
2. 当_main执行完echo Completed后，子Shell准备退出并触发cleanup，但此时cat已经读完了_main的前两行输出，已经退出了
3. 管道的读取端（cat）关闭后，子Shell向管道写cleanup的输出时会收到SIGPIPE信号，导致输出直接被丢弃，根本传不到终端

而不带管道时，_main是在当前Shell进程中执行的，cleanup的输出直接到终端，所以你能正常看到。

验证与解决方法 #

你可以把cleanup的输出重定向到stderr（不经过管道），就能看到陷阱确实触发了：

cleanup () {
    echo "====> Calling cleanup" >&2
}

再运行_main | cat，终端会输出：

Starting
Completed
====> Calling cleanup

如果不想用stderr，也可以避免让trap所在的进程跑在管道子Shell里，比如用命令替换或者重定向的方式替代管道逻辑。

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