From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5134 invoked by alias); 26 Jun 2015 21:08:58 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35620 Received: (qmail 17991 invoked from network); 26 Jun 2015 21:08:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:cc:mime-version:content-type; bh=jtZkoQv7tk0HJF0Qy4CC+XbkGdgsV0J21L8O+noHZzA=; b=hEtD4pw7TPmqUcUgXceieJia/jEQlE+y6Lm5BZ5yeYnrWXeN2LCHmbFn/nzounlKqw NPlAzBfO2GoZ8SXWjpAT0eFD/KWH5q2/5YSr3WuyXcvpp2BKVdx5BuDllTWnXYRbBSxZ DID/YkEba9qo9vco69E4eyzVgCjAZMgH1gJmV2V1dFNvL3hGgXbZgbpgHTVOOV1dVbSl tQD+Vmv0iqDXiODj53N6d1x+Y0YBFpBCWDVjmnBmhhma/KEVAls1HWA9DVBX+trSySfV tu/H0xQx8x+PhlWEaO7VhbOscyssq8oQn4buwreT5bZDX5nyeiihsTyHLp9DdtHqImQs /HpA== X-Gm-Message-State: ALoCoQltDMnD8yLwighuU/+1WSfH57g0eqxvT6v7TWvH+C+5swsObnXCXGIId5VwgkC4qws5XEfw X-Received: by 10.202.186.132 with SMTP id k126mr3118009oif.60.1435352934979; Fri, 26 Jun 2015 14:08:54 -0700 (PDT) From: Bart Schaefer Message-Id: <150626140851.ZM21683@torch.brasslantern.com> Date: Fri, 26 Jun 2015 14:08:51 -0700 In-Reply-To: Comments: In reply to Patrick Palka "TRAPINT function set by parent shell causes subshell to misbehave" (Jun 26, 3:21pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: TRAPINT function set by parent shell causes subshell to misbehave Cc: Patrick Palka MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.