Better ergonomics of error handling is one of the many reasons the author is working on the new shell, Oil. More at https://www.oilshell.org/blog/2018/01/28.htm

Better ergonomics of error handling is one of the many reasons the author is working on the new shell, Oil. More at https://www.oilshell.org/blog/2018/01/28.html https://www.oilshell.org/blog/2018/01/28.html I am working on another one, Next Generation Shell. We agree on the problem, including that error handling in bash is subpar. > good programming requires foreseeing and handling errors I have many small scripts that don't care about errors. Continuing execution in presence of errors is definitely not desirable in these instances, termination is. Ignoring errors is the wrong default for a language, I completely agree with Andy (the author) here. That's why bash has "set -euo pipefail" afterthought. Unfortunately it can't be made the default because of compatibility. Additionally, it has its own quirks. In general, when judging decades old technologies, I do this check: if somebody was inventing the thing today, what would be the reaction? For bash, many choices made then would be unacceptable today. We know better now. Error handling is one of these choices. Another related not stellar thing is the exit code of a Unix process. It was supposed to be enough to convey the status of a program. Non-zero is not always an error (think "test" or "grep"), making generic error handling not possible. These are the decisions that we are paying for.