[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revisiting Error handling (errexit)

From: Lawrence Velázquez
Subject: Re: Revisiting Error handling (errexit)
Date: Mon, 04 Jul 2022 14:59:53 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]