如何确保SIGINT信号不阻断后续命令的执行？

这个问题我之前也碰到过，确实挺让人摸不着头脑的！咱们先理清楚为啥会出现这种差异，再给你几个靠谱的解决办法。

首先得明白两种信号的区别：

• 用kill -9的时候，发送的是SIGKILL信号，这种信号是进程完全没法捕获、忽略或者处理的，sleep会直接被强制终止，而你的shell进程没收到任何信号，自然会继续执行后面的echo命令。
• 但kill -INT或者咱们常用的Ctrl+C发送的是SIGINT信号，这种信号是可以被进程（包括你的shell）捕获的。如果是在终端里直接按Ctrl+C，整个前台进程组（包括运行sleep的进程和你的shell）都会收到SIGINT，默认情况下shell收到这个信号会中断当前的命令序列，所以后面的echo就被跳过了；哪怕你单独给sleep的PID发kill -INT，有些场景下shell也可能因为关联的子进程被信号终止而中断后续执行。

接下来给你几个实用的解决方案：

• 方法一：临时让shell忽略SIGINT，执行完再恢复
  用trap命令临时修改shell对SIGINT的处理，让它暂时忽略这个信号，等命令序列执行完再恢复默认行为。示例代码：

  # 临时忽略SIGINT信号
  trap '' INT
  sleep 100; echo "Finished execution"
  # 恢复shell对SIGINT的默认处理
  trap - INT
  

  这样不管你是按Ctrl+C，还是给sleep发kill -INT，sleep会被终止，但shell会稳稳地执行后面的echo。

• 方法二：把命令放进子shell并捕获SIGINT
  如果你不想改动当前shell的信号处理规则，可以把命令放进子shell里，同时在子shell里捕获SIGINT，确保后续命令不会被中断。示例：

  (
      # 捕获SIGINT，这里可以加个提示信息，也可以空着什么都不做
      trap 'echo "Sleep进程被中断啦"' INT
      sleep 100
      echo "Finished execution"
  )
  

  子shell收到SIGINT后，会先执行trap里的内容，然后继续执行后面的echo，完全不会被信号打断序列。

备注：内容来源于stack exchange，提问作者Hugo Corrá