It would be a good idea if "set -e", "set -o pipefail", and "shopt -s failglob" were enabled for a future EAPI. This will reduce random issues that are hard to debug. This should be enabled in both the global scope and when running phase functions. It basically gets us free trapping of unknown commands for example, along with lots of other advantages. This makes ebuilds less prone to silent failures.
We have previously discussed pipefail, and the conclusion was that it would make legitimate code fail. Examples include "command | grep -q" and "xz -d | tar xf -". See bug 566382.
"set -e" has been discussed too, in 2010: https://archives.gentoo.org/gentoo-dev/message/a92f5f7bdadfaa746507fc11c38baa67
The example in bug #566382 could also fail to catch failures that one intended to catch. If you actually expect the first command in a pipeline to fail, you can do something like: { ./configure --help 2>&1 || true; } | grep -q '^ *--docdir='; printf '%s\n' "${?}" That would make it clear that the first command is expected to fail while not failing the whole pipeline. Certainly "set -e" would make it so one has to check more carefully that the result of random commands is true, but adding "|| true" after a command that is expected might fail is probably a reasonable approach. You could also use the already existing "nonfatal" for these commands as well...
Unfortunately, set -e has some really odd behaviors in bash. For example, try this: bash -c "( set -e; false; echo bad; ) || echo good" There are more examples here: http://mywiki.wooledge.org/BashFAQ/105
(In reply to Zac Medico from comment #4) WONTFIX then?
Yes, sadly set -e appears to be essentially unusable.
