Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 667682 - [Future EAPI] enable "set -e", "set -o pipefail", and "shopt -s failglob" in ebuilds
Summary: [Future EAPI] enable "set -e", "set -o pipefail", and "shopt -s failglob" in ...
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi
  Show dependency tree
Reported: 2018-10-03 23:11 UTC by Patrick McLean
Modified: 2019-03-04 07:14 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Patrick McLean gentoo-dev 2018-10-03 23:11:45 UTC
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.
Comment 1 Ulrich Müller gentoo-dev 2018-10-04 08:35:39 UTC
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.
Comment 2 Ulrich Müller gentoo-dev 2018-10-04 08:41:51 UTC
"set -e" has been discussed too, in 2010:
Comment 3 Patrick McLean gentoo-dev 2018-10-04 21:10:39 UTC
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...
Comment 4 Zac Medico gentoo-dev 2018-11-18 10:12:58 UTC
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:
Comment 5 Ulrich Müller gentoo-dev 2018-11-18 15:42:53 UTC
(In reply to Zac Medico from comment #4)

Comment 6 Zac Medico gentoo-dev 2018-11-18 23:35:05 UTC
Yes, sadly set -e appears to be essentially unusable.