(More) issues with `es -e`

[jpco]

Technically these are more matters of taste than bugs per se, but the following behaviors are cited as unpleasantly surprising in other shells (see https://mywiki.wooledge.org/BashFAQ/105):

In this example, imagine foo is actually a function defined somewhere far away in the script, not "intended" for use in a conditional; it may be unpleasantly surprising that the false there doesn't cause an exit (or throw an exception, with #73):

; let (fn foo {echo a; false; echo b})
if {foo} {
  echo hmm
}

In this example, the following two commands are asymmetrical:

; echo `{echo a; false; echo b}
a b
; cat <{echo a; false; echo b}
a

The second case here is obviously disturbing. The first might not seem problematic, but it's called out as especially egregious in multiple places:

• https://groups.google.com/g/gnu.bash.bug/c/JQZBppS-d3M/
• https://david.rothlis.net/shell-set-e/

(This noticed when reading on elvish's error handling here.)

These might not be worth fixing in es today, but if #73 were merged, it might make sense to take the chance to include these fixes as well. Since I already imagine es -e is used vanishingly rarely, I don't think there's a huge backwards compatibility problem.

[jpco]

So for context, the actual reason echo `{false; echo blah} echoes blah is that the {false; echo blah} thunk is evaluated in the context of a <=. An equivalent but less-obscured-by-syntax-sugar example is that echo <={false; true} also just results in echoing 0.

With that in mind, both of these cases (if and <=) are two aspects of an even more general scenario, where we are saying "run this, and I want to use the result". In the "kill the shell on false" world, in order to actually be able to use the result, we have to turn off the killing behavior - and we do so dynamically, such that if we say if {risky-function} {... or if <=risky-function, then the body of risky-function also runs with the killing behavior disabled, as do forked-off subshells created during risky-function (like in $&backquote), and so on.

None of that is necessary with #73, though; with the power of exceptions, we can just make it so that these "result-using" constructs catch the false exception and use the attached falsey-result-list as the result. I believe this corresponds with the expected behavior that is violated in the links above. I also think it's easier to express the semantics; any command (assignments excluded; but is an assignment technically a command?) throws any false result as an exception. if and <= simply catch those exceptions.

Knock-on effects for -e would also include: {false; echo one} && echo two would not print anything (as && would no longer "cancel" the -e for the {false; echo true}); ! {false; echo true} would not print anything either. {false; echo one} || echo two would only print two. I think these are all reasonable and predictable behaviors for those constructs.

[jpco]

I'm going to close this. #73 can be the place to track these improvements.