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.
