bash - 陷阱 ERR 只工作一次？

我正在编写一个脚本，在启动服务之前等待一堆目录存在。它基本上由一个无限循环组成，该循环在最后中断，或者如果没有找到任何所需的目录，则继续。简化后，算法本身看起来像

loop_while_false() {
    trap continue ERR
    while true; do
        printf .
        sleep 1
        false
        break
    done
    trap ERR
    echo
}

(我知道我可以用 until 或 while ! 完成这个特定的行为，但这与问题无关。)

我第一次运行它时，我得到了一长串点的预期输出，直到我点击 ^c。但是如果我再次运行它，我只会得到一个点。如果我没有点击 ^c，而是将循环重新定义为有限循环，那么在新的 shell 中，陷阱会多次工作。但是为什么 ^c 会打破 shell 生命周期的陷阱呢？更奇怪的是(我在 StackExchange 升级硬件时花了额外的时间)如果你这样写函数，它不会中断:

loop_while_noread() {
    trap continue ERR
    while true; do
        printf .
        read -t1 -n1
        break
    done
    trap ERR
    echo
}

除非你先运行 loop_while_false，然后用 ^c 杀死它。这是一个示例 session :

$ trap -p
trap -- 'shell_session_update' EXIT
$ loop_while_noread
...q
$ loop_while_noread
...r
$ loop_while_noread
....^C
$ loop_while_noread
..q
$ trap -p
trap -- 'shell_session_update' EXIT
trap -- 'continue' ERR
$ loop_while_false
.....^C
$ trap -p
trap -- 'shell_session_update' EXIT
trap -- 'continue' ERR
$ loop_while_false
.
$ loop_while_noread
.

就好像 sleep 或 false 和 trap 之间有一种奇怪的关系。这是预期的行为吗？

我在 OS X El Capitan 上使用 bash 3.2.57(1)-release。

最佳答案

这当然是一个错误。您可以通过将 sleep 命令更改为:

sleep 1||:

我找不到任何错误报告，但是我用 gdb 对 4.3.30(1) 进行了一些测试，并确定在 sleep 1 返回错误后(因为它被中断)，在 trap ERR 的执行中出现了某些问题命令，结果 SIG_INPROGRESS 标志永远不会为 ERR 重置。该标志禁止将来执行 trap ERR ，即使它仍处于启用状态。

我没有进入“执行中出现问题”的部分；当 gdb 跳过 parse_and_execute (trap_command, tag, flags); 时，该函数永远不会返回，我最终回到 bash 提示符处，所以我想在某个时候发生了 longjmp。 (SIG_INPROGRESS 标志将在 parse_and_execute 返回后重置，因此函数不返回的事实解释了为什么不重置标志。)

所有这些操作都在 trap.c 内的 _run_trap_internal 中。

关于bash - 陷阱 ERR 只工作一次？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/35397341/