zsh-workers
 help / color / mirror / code / Atom feed
* TRAPINT function set by parent shell causes subshell to misbehave
@ 2015-06-26 19:21 Patrick Palka
  2015-06-26 21:08 ` Bart Schaefer
  0 siblings, 1 reply; 2+ messages in thread
From: Patrick Palka @ 2015-06-26 19:21 UTC (permalink / raw)
  To: zsh-workers

Hi,

Consider the following testcase:

$ (echo | less)
$ TRAPINT() { }
$ (echo | less)
$ (TRAPINT() { }; echo | less)

During the first execution of (echo | less) -- when a TRAPINT function
is not yet defined -- notice how sending ^C does not kill the 'less'
process or the subshell.

During the second execution of (echo | less) -- after a TRAPINT
function has been defined -- now sending ^C _does_ kill the subshell
(and the 'less' process along with it)

During the third execution of (echo | less) -- after a TRAPINT
function has been defined in the parent shell and redefined in the
subshell -- sending ^C no longer kills the subshell.

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.  When
(echo | less) is replaced with e.g. (nano) then ^C does not kill the
subshell.  Nonetheless I would expect that the 2nd execution always
behaves like the 1st and 3rd executions.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: TRAPINT function set by parent shell causes subshell to misbehave
  2015-06-26 19:21 TRAPINT function set by parent shell causes subshell to misbehave Patrick Palka
@ 2015-06-26 21:08 ` Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2015-06-26 21:08 UTC (permalink / raw)
  To: zsh-workers; +Cc: Patrick Palka

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.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-06-26 21:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-26 19:21 TRAPINT function set by parent shell causes subshell to misbehave Patrick Palka
2015-06-26 21:08 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).