| Summary: | [Future EAPI] Enable 'pipefail' shopt by default | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Michał Górny <mgorny> |
| Component: | PMS/EAPI | Assignee: | Package Manager Specification <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | levertond, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=566342 https://bugs.gentoo.org/show_bug.cgi?id=667682 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
Copied from the other bug (if only I'd waited 15 more minutes): (In reply to Michał Górny from comment #0) > I don't think we really have a use for the former behavior (and even if, it > can be done more clearly using PIPESTATUS) Example based on a line in autotools-utils.eclass (which I realise is deprecated these days; it was just the first concrete example I found in the tree): $ ./configure --help 2>&1 | grep -q '^ *--docdir='; echo $? 0 $ set -o pipefail $ ./configure --help 2>&1 | grep -q '^ *--docdir='; echo $? 141 (Done with paludis's configure since that's what I had conveniently available, but it would happen with any configure script whose --help output is long enough that the grep would exit without reading it all.) It's not a fatal strike against the idea, because as you say it can be written in other ways, but there is a valid reason for the default behaviour, and it may be considered undesirable to make people jump through hoops to get the same thing. Worse, the "obvious" way to write it may work when first written, but then fail if something causes the output to get longer - in some cases, although probably not when testing ./configure output, it may even depend on the local configuration, and so might break for users when it worked for the developer. (In reply to Michał Górny from comment #0) > As a side note, if we do that then the assert command becomes redundant and > we can ban it via bug #566342. These are really separate issues, because the assert command came into existence independent of PIPESTATUS. Its original variant tested the $? status; it was later updated to test PIPESTATUS instead, in bug 25929. Well, David's argument seems strong enough to convince me not to do this. WONTFIX? |
The 'pipefail' shopt affects the meaning of $? after pipelines: 1. with pipefail off (the default), $? contains the exit status of last command in the pipeline (i.e. ${PIPESTATUS[-1]}), 2. with pipefail on, $? contains the exit status of last *failed* command or 0 if all commands succeeded (requires checking all PIPESTATUS args right now). I don't see a real use for behavior described in (1), and if it's ever needed, it can be easily replaced with (more reliable) PIPESTATUS reference. On the other hand, the behavior described in (2) can be used to easily and quickly check pipeline for failures. In fact, with pipefail on, it is possible to write: cmd1 | cmd2 | cmd3 || die "one of the commands on the pipeline failed!" which is both convenient and more foolproof than the default. Therefore, I suggest we enable pipefail in a future EAPI. As a side note, if we do that then the assert command becomes redundant and we can ban it via bug #566342.