Re: Revisiting Error handling (errexit)

[Yair Lenga]

Hi Lawrence,

I'm sorry - I misunderstood your original comments. I'll prepare the
patched version (at least, I would like to add comments before
publishing...) , and share it.
Where/how can I post it ? I did not see anyone else dropping source
code/patches into the group ?

Yair

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

> On Mon, Jul 4, 2022, at 2:33 PM, Yair Lenga wrote:
> > Thanks for taking the time to review my post. I do not want to start a
> > thread about the problems with ERREXIT.
>
> Neither do I.
>
> > Instead, I'm trying to advocate for
> > a minimal solution.
> >
> > [...]
> >
> > 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, &&, ...).
>
> So what does your proposed option actually *do*?  You're continuing
> to provide examples of changed behavior, instead of explicitly
> *describing the changes*.
>
> If you don't understand what I'm asking for, just send a patch.
>
> > 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.
>
> The "development team" is one person.  (That person isn't me, to
> be clear.)  He's not averse to outside contributions, but there's
> no guarantee that he'll agree with your goal in the first place.
>
> Again, you might as well send what you have without worrying too
> much about polishing it.  You can always submit refinements later.
>
> --
> vq
>