Re: Revisiting Error handling (errexit)

[Yair Lenga]

Lawrence,

Thanks for taking the time to review my post. I do not want to start a
thread about the problems with ERREXIT. Instead, I'm trying to advocate for
a minimal solution. There are already many threads in bash mailing lists,
stack overflow, and numerous articles related to advanced bash programming
(google "bash errexit problems", e.g.
https://stackoverflow.com/questions/13870291/trouble-with-errexit-in-bash
). Please take a look at the specific short example that I listed (below).
I believe fair summary is the the behavior defined by the POSIX spec is
less than ideal.

#! /bin/bash
set -e
function foo { echo BEFORE ; false ; echo AFTER ; }
foo || echo FAIL

Where the expected output is "BEFORE ... FAILED, but actual output is
"BEFORE ... AFTER". The root cause is the way "errexit" (-e) is handled in
functions, statements-lists, ... when combined with control statements (if,
while, &&, ...).

As for my question about code being accepted - I'm trying to figure out if
the bash development team is open to outside contributions. Some projects
are not open to contribution. If bash is open to contribution, I'll prepare
the code for submission/review (style, comments, test cases, ...) as
needed. Was not implying for blank approval ;-)

Regards,
Yair

On Mon, Jul 4, 2022 at 7:41 PM Lawrence Velázquez <vq@larryv.me> wrote:

> On Mon, Jul 4, 2022, at 8:20 AM, Yair Lenga wrote:
> > I was able to change Bash source and build a version that supports the
> new
> > option 'errfail' (following the 'pipefail' naming), which will do the
> > "right" thing in many cases - including the above - 'foo' will return 1,
> > and will NOT proceed to action2. The implementation changes the
> processing
> > of command-list ( '{ action1 ; action2 ; ... }') to break of the list, if
> > any command returns a non-zero code, that is
> >
> > set -oerrfail
> > { echo BEFORE ; false ; echo AFTER ; }
> >
> > Will print 'BEFORE', and return 1 (false), when executed under 'errfail'
>
> This is already how errexit behaves in most contexts.
>
>     % bash -ec '{ echo BEFORE; false; echo AFTER; }'; echo "$?"
>     BEFORE
>     1
>
> So what did you actually change?  Presumably you tweaked the special
> treatment given to the conditional portion of "if" commands, but
> we shouldn't have to guess.
>
> > I'm looking for feedback on this implementation. Will be happy to share
> the
> > code if there is a chance that this will be accepted into the bash core
> > code
>
> I don't think there's a chance unless you share the code first.
> Your description is wholly inadequate for understanding the true
> nature of your proposal.
>
> --
> vq
>