Hi Martin,
Thanks for taking the time to review my proposal.
Wanted to highlight that the implementation was less than 3 hour (fun) job - no
trouble at all. Credit should go to current bash dev team (I am being told it’s
a team of 1) - for keeping organized, well written, documented code !
I’m not in front of my desktop, so I can not verify behavior, but here is my
expectation - let me know if it make sense, in the context of the project goal
- every unhandled failed statement should unwind execution up, until explicitly
handled. “Up” means current semi-colon connected statement - in a group, sub
shell or a list.
> if false ; echo Foo ; [[ notempty ]] ; then echo Full ; else echo Empty ; fi
> || echo Fail
>
Output: Empty
If false … should fail on the first false, going to the else part, printing
Empty. Since the ‘echo empty’ succeeded, Fail will not be printed.
> or
>
> if { false ; echo Foo ; [[ notempty ]] ; } ; then echo Full ; else echo Empty
> ; fi || echo Fail
>
Output: Empty
Same as above. Grouping does not change behavior.
> or
>
> if ( false ; echo Foo ; [[ notempty ]] ) ; then echo Full ; else echo Empty ;
> fi || echo Fail
>
Output: empty
Same as above. Running in a subshell does not change behavior.
> or
>
> for x in a b ; do if false ; echo Foo ; [[ notempty ]] ; then echo Bar ; else
> echo Empty ; fi ; done
Output: Empty (for a), Empty (for b)
Since the if statement succeed, the code will flow to from the first iteration
to the second iteration.
The last case has interesting variant: the case when the loop body fail (for x
in a b ; do echo $x ; false ; done.
Output: a
In this case, the code failed body will result in effective ‘break’ to the
loop, where the whole for statement will fail. I believe this case is not
currently covered in the implementation (2 or 3 lines to cover each of the loop
constructs: for (list, arithmetic), until and while.
Thank you for proposing those test cases. I will add a small verification
script with all those cases to my submission - I need to prepare the patch
against the dev branch.
Regards,
Yair.
Sent from my iPad
> On Jul 5, 2022, at 7:27 PM, Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
>
>
> Before going to the trouble of implementing this, I think it's worth having a
> discussion about the precise semantics.
>
> The examples given suggest that if a command has an un-tested non-zero exit
> status, that it will cause the current function to return that status
> immediately.
>
> But what about other compound statements?
>
> What do you propose should be the output (if any) from:
>
> In short, how far does unwinding this propagate, and what stops it?
>
> -Martin
