在bash脚本中，当信号被困时会发生什么

Question

假设我正在运行以下示例保存为 hello.sh ，

#!/bin/bash
hello() {
    echo "hello"
}

trap "hello" INT
sleep 100
echo "end"

而在Shell I开始 Hello.sh 。 1秒钟后，我按 ctrl-c 。

请将睡眠视为我开始的任何长期过程。

这是我的问题：

1. 当生成 sigint 时，它是直接传递到 Sleep 还是直接发送给Shell脚本？
2. 如果是第二个，我可以让睡眠有机会处理 sigint ，并且不传播其父 hello.shy.sh 吗？
3. 如果是第一个，睡眠的状态是什么？

我的测试使我觉得以下发生在

1. 睡眠开始运行
2. hello.sh 接收到信号
3. 函数 Hello 开始运行
4. 函数 > Hello 完成
5. echo“ end” 开始运行
6. 脚本退出。

但是在哪个阶段，睡眠过程退出，并且由于什么（例如Sigint停止了 Sleep 过程？）

Answer 1

$ cat foo.sh
_sigint()
{
    echo "received SIGINT"
}

trap _sigint INT

sleep 10000
echo "status=$?"
$ bash foo.sh              # <-- start foo.sh and then press CTRL-C
^Creceived SIGINT
status=130

一些解释：

• sleep 作为 bash 的子进程运行。 bash 和 sleep 在同一个进程组中运行，该进程组现在是前台进程组。

• 当按下CTRT-C时，它将生成SIGINT，并且该信号将发送到中的所有进程前台进程组，因此 bash 和 sleep 都会收到 SIGINT。

• 根据bash 手册 ^{（可以另请参阅man bash）}

  <块引用>

  如果 bash 正在等待命令完成并接收到已设置陷阱的信号，则陷阱将不会执行直到命令完成。

  所以这里bash会等待sleep被杀死^{（默认的SIGINT行为是终止进程。请参阅signal(7))} 首先，然后 bash运行它的SIGINT 陷阱。

• 根据 bash 手册

  <块引用>

  简单命令的返回值是其退出状态，如果命令由信号 n 终止，则为 128+n。

  SIGINT 为 2 ^{（请参阅 kill -l）}，因此 sleep 的退出状态为 128+2=130。