为什么bash errexit在函数调用中的行为不如预期？

Question

在bash手册页中，它指出：

如果管道（可能由单个简单命令组成）、
括号中包含的子shell命令，或作为大括号中包含的命令列表的一部分执行的其中一个命令。。。

所以我假设一个函数应该被视为一个用大括号括起来的命令列表。但是，如果将条件应用于函数调用，errexit将不再在函数体中存在，它将在返回之前执行整个命令列表。即使在函数内部显式创建了一个子shell，并为该子shell启用了errexit，命令列表中的所有命令都会执行。下面是一个简单的例子来说明这个问题：

function a() { b ; c ; d ; e ; }
function ap() { { b ; c ; d ; e ; } ; }
function as() { ( set -e ; b ; c ; d ; e ) ; }
function b() { false ; }
function c() { false ; }
function d() { false ; }
function e() { false ; }

( set -Eex ; a )
+ a
+ b
+ false

( set -Eex ; ap )
+ ap
+ b
+ false

( set -Eex ; as )
+ as
+ set -e
+ b
+ false

现在如果我对每一个应用一个条件。。。

( set -Eex ; a || false )
+ a
+ b
+ false
+ c
+ false
+ d
+ false
+ e
+ false
+ false

( set -Eex ; ap || false )
+ ap
+ b
+ false
+ c
+ false
+ d
+ false
+ e
+ false
+ false

( set -Eex ; as )
+ as
+ set -e
+ b
+ false
+ c
+ false
+ d
+ false
+ e
+ false
+ false

Answer 1

这不是对原始问题的回答，而是针对根本问题的解决方案：设置错误陷阱：

function on_error() {
    echo "error happened!"
}
trap on_error ERR

echo "OK so far"
false
echo "this line should not execute"

行为本身的原因在其他答案中得到了正确的解释（根据手册和POSIX，基本上是预期的bash行为）：https://stackoverflow.com/a/19789651/1091436

Answer 2

bug bash邮件列表中Eric Blake对函数的解释更加明确：

简短的回答：历史兼容性。

...

事实上，POSIX要求的正确行为（即在f（）的整个主体期间完全忽略“set-e”，因为f是在忽略“set-e”的上下文中调用的）并不直观。但它是标准化的，所以我们必须接受它。

以及一些关于是否可以利用set-e来实现所需行为的单词：

因为一旦你处在一个忽略“set-e”的上下文中，历史行为就是，对于被忽略的上下文中的整个代码体，没有进一步的方法来重新打开它。30年前，在真正考虑外壳功能之前，它就是这样做的，我们被这个糟糕的设计决策所困扰。

Answer 3

你开始引用手册，但后来你删掉了解释这种行为的部分，这是在下一句：

-e如果管道（可能由单个简单命令、括号内的子shell命令或作为大括号内命令列表的一部分执行的其中一个命令组成）返回非零状态，则立即退出。如果失败的命令是紧跟在之后的命令列表的一部分，而或直到关键字，在if语句中测试的一部分，在语句中执行的任何命令的一部分，则shell不会退出