Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 566382

Summary: [Future EAPI] Enable 'pipefail' shopt by default
Product: Gentoo Hosted Projects Reporter: Michał Górny <mgorny>
Component: PMS/EAPIAssignee: PMS/EAPI <pms>
Status: RESOLVED WONTFIX    
Severity: normal CC: levertond
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    

Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-21 13:21:34 UTC
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.
Comment 1 David Leverton 2015-11-21 13:43:33 UTC
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.
Comment 2 Ulrich Müller gentoo-dev 2015-11-21 14:12:30 UTC
(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.
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-21 22:20:59 UTC
Well, David's argument seems strong enough to convince me not to do this. WONTFIX?