bash函数含子进程时SIGINT/退出行为不一致问题排查

1. 原版本直接执行command的信号行为 #

当你在函数循环中直接运行command时：

• command是函数所在shell的直接子进程，二者同属前台进程组。
• 按下Ctrl+C时，终端会将SIGINT发送给整个前台进程组的所有进程：
  • command收到SIGINT后终止，退出码为128+2=130（对应SIGINT的信号编号）。
  • 父shell（运行函数的shell）也会收到SIGINT，但交互式shell的默认行为是终止当前执行的命令（即command），但不会退出自身，因此循环会继续执行下一次迭代——这就是你最初遇到的“软锁”问题，SIGINT触发command退出后函数会重试。

2. 命令替换$(command 2>&1)的信号行为变化 #

命令替换$(...)会让shell创建一个独立的子shell进程来执行括号内的命令，这直接改变了信号传播的路径：

• command成为子shell的子进程，而子shell与父shell的进程组关系发生了变化：当command等待用户输入时，它是前台进程组的成员，而父shell处于等待子shell完成的后台状态，因此终端发送的SIGINT/SIGTSTP只会直接发给command，不会发给父shell。
• 当command被SIGINT/SIGTSTP终止/暂停时，子shell会检测到子进程的异常退出状态，并将自身的退出状态设置为信号终止对应的码（比如SIGINT对应130）。
• 关键问题：bash等主流shell在处理命令替换时，如果子shell是因为信号导致的异常退出，父shell会直接终止当前正在执行的脚本/函数，跳过后续的if-else逻辑。这就是为什么你添加的trap没有生效——信号根本没有发送给父shell，父shell是因为子shell的异常退出状态而直接终止执行的。

补充：关于trap不生效的原因 #

你在父shell中设置的trap只对父shell自身收到的信号生效，而命令替换中的command收到的信号不会转发给父shell。同时，子shell会继承父shell的trap，但command被信号终止时，子shell的trap如果没有专门处理，也不会触发父shell的逻辑，最终子shell异常退出导致父shell终止执行。

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