Andreas Grünbacher wrote: > Hi all, > > the errexit option can be very useful in simple scripts. This option > is being ignored in many contexts like lists and conditionals though. > I understand that this is "by design" and that errexit cannot be > "fixed" to behave more reasonably. Still, this makes bash a lot less > useful than it could be; working around this limitation is painful, > ugly, and leads to fragile code. > > So, since we cannot "fix" errexit, can we maybe introduce another > option like "errfail" that behaves like errexit for simple commands, > but is also logically composable? Let me show what I mean with the > following pseudo-code:
I think you should explicitely state where and you would like it not to do it. I find unlikely to develop it, but at least they could be documented, with its workarounds. On some cases with non-POSIX features, maybe the behavior could be changed for some non-POSIX (eg. the change of arighmetic expansion on bash-4.1) For reference, the current doc says: > if the > failed command is part of the command list immediately following > an `until' or `while' keyword, part of the test following the `if' > or `elif' reserved words, part of a command executed in a `&&' or > `||' list except the command following the final `&&' or `||', any > command in a pipeline but the last, or if the command's return > status is being inverted using `!' > > set -o errfail > fail() { > false > echo 'oops!' >&2 # not reached > } > ! fail > fail || : > if fail; then > : > fi > set -- `fail` # script fails here > echo 'oops!' >&2 # not reached This seems to request a change on two cases: - inherit the errexit flag into functions - make shell expansions fail the command including them For the first one, I don't see a spec reason for that, other than "it has been done like that", requiring an explicit set -o errfail. Maybe the set options should be inherited for set -E While we discuss it, I find odd that this code doesn't run the trap inside a function but does outside: > fail() { > trap "echo trap executed" ERR > false > } As for the second option, I also missed such a ability a while back, but was able to get the expected behavior with the workaround: > FAIL=$(fail) > set -- $FAIL > Having such an option would certainly make bash a lot more useful to me. > What do you guys think, could such an option be implemented with > reasonable effort? I don't think it would require special effort, but IMHO adding a _slightly different errexit_ wouldn't be appropiate. Changing errexit semantic, has a big potential for broken scripts. And having readily available workarounds…