Each time though, you've removed the NEWS item. Although we've
established that the behavior it describes was not actually
appropriate, there still has been a change in ERR_EXIT behavior that
probably warrants a mention. What's the best description of that?
Good point. There is indeed a behavior change but it's more complicated than what you described. I will try to come up with something. Actually my 3 fix patches address 3 different issues. In my opinion, at least 2 of them qualify as bugs but it still makes sense to describe what changes.
This suggests that anonymous
functions should *not* behave like normal function calls here.
That's debatable. If, like me, you see anonymous functions as some kind of syntactic sugar, then it makes sense that they behave like function calls and exit. However, I can also understand that others rather see them as another type of compound command. In that case, they should not exit.
To help decide what to do, here is a table that lists all the different cases and how they behave in the current Zsh, in a patched Zsh, and in a patched Zsh where anonymous functions behave as compound commands:
Code Current Zsh Patched Zsh Compound command (and patches)
A) false Exit Exit Exit
B) false && true No exit No exit No exit
C) { false && true } No exit No exit No exit
D) () { false } Exit Exit Exit
E) () { false && true } Exit Exit No exit
F) () { { false && true } } No Exit Exit No exitG) f() { false }; f Exit Exit Exit
H) f() { false && true }; f Exit Exit Exit
I) f() { { false && true } }; f No Exit Exit Exit
Currently anonymous functions behave like function calls. My patches don't change that but they change/fix cases F and I to behave as mandated by POSIX. If anonymous functions are changed to behave like compound commands then anonymous functions behave as if the code was inlined. This changes the behavior of case E, which currently exits.
Is the compound command behavior a reasonable one? Certainly yes. Is it desirable? I guess that's more debatable. Personally, I am leaning towards the current behavior. I could be convinced otherwise and for sure I could live with the alternative.
If you care about code complexity (of the Zsh implementation), then that would be an argument against the compound command option as it requires additional code. However, in my opinion, languages should in general NOT be designed to simplify their implementation but rather to simplify their usage.
Does it? These seem to behave identically with Philippe's latest
patches; am I overlooking something?
No, with my patch "false && true" and "{ false && true}" now always behave the same.
Frankly I'm
still not certain that the extra level of { } should matter in the
function example.
With my patches, they no longer do. Note however that the behaviors of the following examples, which are unaffected by my patches:
set -e
{ false && true } # does not exit
() { false && true } # exits
As you can see, with my patches, an extra level of { } no longer changes any behavior. However, already today, anonymous functions don't always behave the same as the inlined code.
FYI: Here are my next steps
- Write NEWS for my 3 fixes.
- Better document the role and usage of noerrexit and this_noerrexit.
- Try to fix "eval", "source", and possibly a bunch of other related cases.
Unless anyone sees a reason not to, it would be nice to submit my first pacth, which reverts Bart's changes. For the other patches, I have at the very least to first add a NEWS item.
Philippe