Re: Revisiting Error handling (errexit)

[Greg Wooledge]

On Fri, Jul 08, 2022 at 01:52:04PM +0300, Yair Lenga wrote:
> While you can achieve results similar to 'errfail' with existing bash
> commands (you will need more than && !), the required effort is not
> practical:
> * Consider a common scenario (for me) - a script with 1000 lines, complex
> logic, commands than span multiple lines - there is no practical way to
> review the scripts, and enter the '&&' into hundreds of lines - in the hope
> of not breaking anything, including scripts that generate code on the fly
> (The 'evil' eval :-).

What I'm seeing here is:

1) You have a bunch of thousand-line bash scripts.  This is already a huge
   red flag.

2) These thousand-line scripts are poorly written, possibly even broken.
   (Not a surprise!  Anyone who would write such a thing in the first
   place is practically guaranteed to do it poorly.)

3) Rather than rewriting them so that they're not broken, you would like
   to change *the shell itself*, so that the shell will apply simplistic
   checks and magically make it all better (the way "set -e" was
   originally intended, but failed, to do).

Of course, there is no magical way the shell can know which error codes
are significant, and which are not.  Your proposal forces the script
writer to make that classification, and add ||true to all of the commands
whose exit status should be disregarded.

It's hard to see how the effort of identifying those commands and applying
all of those ||true suffixes is much different from the effort that would
be needed to (re)write the scripts with proper error handling in the first
place, so that they can run under a standard shell without special patches.