只是为了多样性，我将发布https://stackoverflow.com/a/2173421/102484的变体，因为这个解决方案在我的环境中会导致消息“终止”:

trap 'test -z "$intrap" && export intrap=1 && kill -- -$$' SIGINT SIGTERM EXIT

一个可以在Linux、BSD和MacOS x下工作的不错的版本。首先尝试发送SIGTERM，如果不成功，10秒后终止进程。

KillJobs() {
    for job in $(jobs -p); do
            kill -s SIGTERM $job > /dev/null 2>&1 || (sleep 10 && kill -9 $job > /dev/null 2>&1 &)

    done
}

TrapQuit() {
    # Whatever you need to clean here
    KillJobs
}

trap TrapQuit EXIT

请注意，作业不包括子代进程。

更新:https://stackoverflow.com/a/53714583/302079通过添加退出状态和清除功能改进了这一点。

trap "exit" INT TERM
trap "kill 0" EXIT

为什么转换INT和TERM退出?因为两者都应该在不进入无限循环的情况下触发kill 0。

为什么在EXIT时触发kill 0 ?因为正常的脚本退出也应该触发kill 0。

为什么要杀死0?因为嵌套的子shell也需要被杀死。这会把整个过程树都画下来。

如果在子shell中调用Jobs -p，则不能在所有shell中工作，除非它的输出被重定向到文件而不是管道中。(我想它最初只是用于交互使用的。)

下面这些怎么样:

trap 'while kill %% 2>/dev/null; do jobs > /dev/null; done' INT TERM EXIT [...]

Debian的dash shell需要调用“jobs”，如果缺少当前作业(“%%”)，则该shell无法更新。

为了安全起见，我发现最好定义一个清理函数并从trap中调用它:

cleanup() {
        local pids=$(jobs -pr)
        [ -n "$pids" ] && kill $pids
}
trap "cleanup" INT QUIT TERM EXIT [...]

或完全避免该函数:

trap '[ -n "$(jobs -pr)" ] && kill $(jobs -pr)' INT QUIT TERM EXIT [...]

为什么?因为通过简单地使用陷阱'kill $(jobs -pr)'[…]当陷阱条件发出信号时，就会有后台作业在运行。当没有工作时，会看到以下(或类似的)消息:

kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

因为jobs -pr是空的——我在那个“陷阱”中结束了(双关语)。

另一种选择是让脚本将自己设置为进程组的领导者，并在退出时在进程组上捕获killpg。