bash - 如何在 bash 脚本中正确捕获 SIGQUIT？

Question

我可以编写捕获 SIGINT 的 shell 脚本，但我似乎无法捕获 SIGQUIT。

#!/bin/bash

function die {
    echo "Dying on signal $1"
    exit 0
}

trap 'die "SIGINT"' SIGINT
trap 'die "SIGQUIT"' SIGQUIT

while true; do
    echo "sleeping..."
    sleep 5
done

执行此脚本并按 CTRL-C 会产生预期的效果，但按 CTRL-\(据我所知，应该会触发 SIGQUIT) 除了在终端打印 ^\ 什么都不做。为什么？

我有两个运行理论。首先是 SIGINT 和 SIGQUIT 的语义不同，因此 SIGQUIT 只发送给子进程 sleep，同时 SIGINT 被发送到子进程和父 bash 进程。如果是这种情况，它记录在哪里？

我的第二个理论是 bash 不仅在默认情况下忽略(即，有一个空操作处理程序)SIGQUIT(如手册页所建议的)，而且不允许它被困在全部。该理论与第一个理论重叠，因为可能是 SIGQUIT 将同时发送给父项和子项，但父项 (bash) 无法捕获它.如果是这种情况，是否有任何方法可以在 bash 脚本中捕获 SIGQUIT？...也许我可以设置一些 shopt？

编辑:这是在运行 bash 4.1.5 的 gnome-terminal 2.32.0 中的 Ubuntu 10.10 上，是的 ^\ 被配置为发出 SIGQUIT(如 stty -a< 所报告 并通过向其他程序(如 ping)发出 ^\ SIGQUIT 来确认。

更新:我刚刚发现问题一定是由于 gnome-terminal 引起的。如果我从虚拟控制台运行此脚本(即，ctrl-alt-f1 以退出 X)，当我按下 ^\ 时它会完美捕获 SIGQUIT。相同的 bash 和一切，所以唯一的区别一定是终端仿真器。所以现在我的问题变成了:如何配置 gnome-terminal 在这方面表现得像虚拟控制台？我在虚拟控制台和 gnome 终端中 diff 了 stty -a 的输出，虽然有差异，但似乎没有什么是直接相关的(例如，它们都有quit = ^\;).

更新 2:另一个实验。只需在 gnome 终端中执行 $ sleep 60；按 ^\ 信号未被捕获。现在在虚拟控制台中执行$ sleep 60；按 ^\ 信号 被 捕获——进程打印 Quit 并退出。但是现在在 gnome 终端中运行 $ ping google.com 并按 ^\ —— 信号被捕获并按预期处理。所以 gnome-terminal 有一些奇怪的地方，以至于 SIGQUIT 可以被一些程序捕获，但不能被其他程序捕获，即使其他那些程序在从虚拟控制台调用时 确实 捕获了它。也许我应该升级我的 gnome 终端。

Answer 1

我只能假设这是 gnome-terminal 2.32.0 中的某种错误；我已经升级到 Ubuntu 11.04，gnome-terminal 2.32.1(和 bash 4.2.8)并且 SIGQUIT 现在如预期的那样被困住了。