Re: TRAPINT function set by parent shell causes subshell to misbehave

[Bart Schaefer <schaefer@brasslantern.com>]

On Jun 26,  3:21pm, Patrick Palka wrote:
}
} So when a TRAPINT function is defined in the parent shell and not
} redefined in the subshell, then the subshell decides to exit when
} SIGINT is sent to it -- at least when the 'less' command is run.

In part this is because "less" installs its own trap for that signal,
but there may be a bug in the handling of the TRAPS_ASYNC option.

(remarks below refer to zsh-5.0.8, behavior may differ in older versions)

In the first case, less and the subshell both receive the signal but
both ignore it.  In the second case they both receive it but only less
ignores it.  In the third case they both receive it, less ignores it,
and the subshell waits for less to exit before processing it.

Thus in the second case where you think both the subshell and less have
been killed, you are actually not quite correct -- the subshell was
interrupted, but less exited on its own as a side-effect.

You can see what's going on if you define

    zmodload zsh/system
    TRAPINT() { print $$ $sysparams[pid] }

In the second case, the parent shell receives the signal and kills the
subshell.  In the third case, the subshell receives the signal because
it has redefined the trap ($$ and $sysparams[pid] differ in the trap).

If instead you use the "trap" command instead of defining the function,
the parent shell also waits before processing the signal.  I'm not sure
if this is as intended or not; changing TRAPS_ASYNC makes the second
and third cases both handle the trap immediately, no matter which way
of defining the trap was used.