The way we define 'assert' is highly confusing and completely different from all regular programming languages. Additionally, the function is barely used and can be easily replaced by less confusing direct PIPESTATUS check. I think we should ban it.
Huh? What would be used as replacement? Testing PIPESTATUS is not a viable alternative because it is clumsy and cannot be done without a loop. IMHO we shouldn't remove working functionality without good reason.
Actually, the name of the function had been discussed in gentoo-dev. Apparently, assert_true_or_die() and success_or_die() had been proposed as alternative names and they finally settled on the assert() variant: https://archives.gentoo.org/gentoo-dev/message/f11752e18c1f8f6732ceaaac16964ffa https://archives.gentoo.org/gentoo-dev/message/b0ffef8809ea760d53a06d9c25265c50
How about enabling pipefail instead?
(In reply to Michał Górny from comment #3) > How about enabling pipefail instead? I don't think that's really feasible, for similar reasons that using 'set -e' was rejected in favor of just having helpers die by default in EAPI 4 (see bug 138792).
(In reply to Zac Medico from comment #4) > (In reply to Michał Górny from comment #3) > > How about enabling pipefail instead? > > I don't think that's really feasible, for similar reasons that using 'set > -e' was rejected in favor of just having helpers die by default in EAPI 4 > (see bug 138792). Actually, after reading the pipefail documentation in the bash man page, I think the behavior might be reasonable (as long as we don't also enable 'set -e'.
I'm with Zac here. Rewording what the manual says: - without it, $? has the exit code of last process (i.e. PIPESTATUS[-1]), - with it, $? has the exit code of last *failing* process or 0 if none failed. I don't think we really have a use for the former behavior (and even if, it can be done more clearly using PIPESTATUS), while the latter makes $? have behavior equal to the current assert implementation. In fact, it makes it possible to safely just: cmd1 | cmd2 | cmd3 || die ...
Can you please open a new bug for pipefail? Seems that enabling that option doesn't necessarily imply banning assert.
(In reply to Michał Górny from comment #6) > 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. (Apologies for continuing the OT on this bug, but the one for pipefail hasn't been opened yet.)
As we won't have pipefail, I don't think that we will go forward with this one either. WONTFIX.
