I think the fundamental problem here could be overcome by implementing the err_return option from zsh. When a function fails partway through, err_return causes the function to return early, rather than exiting.

There is definitely a problem with the current behaviour (despite being compliant with POSIX). I really dislike the fact that bash ignores err_exit inside a function called from a conditional. Sometimes this can be avoided (clumsily) by calling the function directly, then testing the function return status via $?, but there are other cases (e.g. when the function is called via the time builtin) where this solution will not work. I have one of these cases.

err_return would solve this problem, and would not break POSIX compliance, because it would be off by default.

комментарий №3:

>
> It's a case of mismatched expectations. `set -e' isn't as useful as you
> hope it will be.

Well, very bad, because there aren't any reasons not to make it (or some additional to it) useful, just strange design issue. Very bad and important issue, because `set -e` functionality can be very useful, but now is very dangerous and so - should never be used anywhere to avoid problems.

I'm absolutely sure that manpage must be corrected to explicitly specify that state of disabling trap ERR is inherited to all execution levels, can not be overrided, and so, trap ERR usage in subshells and functions are very dangerous and very limited. Because if you don't know bash on professional level (as most bash users) - you willn't understand it by current man.

Moreover. `set -E` and `trap ERR`, as I understand, are not a POSIX standad and I do not see any reasons not to make them working normally.

So, I think that bash shoud have a "Feature request" bug. At least, bash should correct manpage. Then - bash can implement some replace of POSIX `set -e`, that will not inherite disabled state, and should switch trap ERR to that behavior too (at least allow to force enabled state by trap ERR inside functions etc). It's a super easy task - just reset global variable on each fork and each function call.

Why not to allow users use trap ERR in their scripts as it should  be used? So script (or any subshell) must generate ERR on every non-catched error, no matter where it is (in function, in subshell etc). It's very good feature, moreover, as I understand, it's already implemented, but disabled for compatibility with POSIX `set -e`. Currently, all features related to ERR are almost useless, but it's very easy to make them useful.

The fact that bash have error handling functionality, but it is broken (for any programmer, who want to use it) for some strange reasons (no matter that are written in POSIX or internally implemented - you always can add new flag, it's a bash, not ash or similar) - it is certanly an important bug. Hope that it will be fixed, because it's very hard to write complex big scripts without working trap ERR (|| catch_err on every line - it's a more or less working solution, but very strange solution)

comment #1:

> `set -e' (and consequently the ERR trap) is not in effect when the command is on the left side of an AND-OR list.
>
> There are other situations where set -e is ineffective; there is a full list in the man page.
>

comment #1:

> `set -e' (and consequently the ERR trap) is not in effect when the command is on the left side of an AND-OR list.
>
> There are other situations where set -e is ineffective; there is a full list in the man page.
>

Man page:

The ERR trap is not executed if the failed command is part of the command list immediately following a while or until keyword, part of the test in an if statement, part of a command executed in a && or || list except the command following the final && or ||, any command in a pipeline but the last, or if the command's return value is being inverted using !. These are the same conditions obeyed by the errexit (-e) option.

echo 12>/SOME/NONEXISTING/FILE is not a part of anything from this list. Call of function is a part, not the commands inside. Logically it's absolutely different things. It's even another process! Moreover, from topic about set:

-E      If set, any trap on ERR is inherited by shell functions, command substitutions, and commands executed  in  a  subshell  environment.

No, this flag will never work in real cases! Please, at least add comments about set -e, trap ERR and set -E to manpage and clarify that this functionality can't be used with functions, subshells and sourced files if you want to check result code from it.

Current manpage tells that set -e should kill my subshell inside function and that you can use set -E to export traps always (but you can't in general case)

But. Currently there are no way to check errors inside functions. I really don't understand why bash do not work as expected and as it's written in man. Bash should disable ERR only on current code level, and do not in calling functions. Without it set -e can't be used.

I'm trying to use trap ERR inside my scripts and suddenly realise that it doesn't work at all in most cases, because I split my scripts to functions and libraries.

Test case:

function hmmm() {
    trap 'exit 10' ERR
    echo 12>/SOME/NONEXISTING/FILE
    # some commands that must not be done ever if previous has failed
    echo "THAT MUST NOT BE PRINTED" >&2
    return 5
}  

echo ok1
a=$(hmmm) || status="$?"
echo "function returns: $status"

What I expect to see:

ok1
test2.sh: line 3: /SOME/NONEXISTING/FILE: No such file or directory
function returns: 10

But I see:
ok1
test2.sh: line 3: /SOME/NONEXISTING/FILE: No such file or directory
THAT MUST NOT BE PRINTED
function returns: 5

So set -e absolutely unusefull in functions (because you can't use it with returning something), and, that also important, in libraries, which should be sourced with 'source "mylib.sh" || exit 1' (everyone always add '|| exit 1' or smth similar after source, so 'set -e' will never works inside libraries).

Moreover, as I understand, there aren't any working method to enable trap ERR inside subshells, functions and libraries.

This bug is very important because you can accidentally disable errors trapping inside some third-party libraries or functions easily and willn't ever know about it till this library will do rm -rf /.

Constructions 'somecode || true' must always disable errors only on current execution level, not inside called functions or other types of code.

GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)