Re: Bug with traps and exit

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Tue, 2019-12-17 at 07:31 +0000, Daniel Shahaf wrote:
>Bart Schaefer wrote on Sun, Dec 15, 2019 at 22:37:53 -0800:
>>On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> workers/44007 (also in this thread):
>>>
>>>> trap 'printf $1; exit; printf $2' USR1
>>>> fn() {
>>>>          printf 1
>>>>          kill -s usr1 $$
>>>>          printf 2
>>>> }
>>>> printf 0
>>>> fn A B
>>>> printf 3
>>> 
>>> Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.
.....
> - exit_pending is set
>
> - The remainder of the trap is skipped (I assume that's because
> bin_break() set retflag?)
>
> - The remainder of fn() is executed

I guess this is where the problem is.  We should presumably continue to
skip through the function, too.  We may be reesetting "breaks" when we
shouldn't be, for example, or failing to propagate some other condition,
perhaps just the effect of the exit_pending.

>> The trouble is that we also have to treat differently the cases of the
>> trap having been set inside the function, and the trap existing
>> outside the function when the function is called.
>
> Why?

I'm not sure that's necessarily ture of USR1 traps --- I can't think of
why the *effect* would be different, even if the trap is local to the
function --- but one of our big headaches is EXIT traps which in zsh are
triggered at the end of the enclosing context.  (An exit in an exit
trap is even worse).  Luckily, we don't have to deal with exit traps
in this case, but we do have to be sure we're not doing anything that
will have a knock-on effect there.

pws