From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27356 invoked by alias); 16 Sep 2011 17:46:01 -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: 29782 Received: (qmail 314 invoked from network); 16 Sep 2011 17:46:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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 autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) MIME-Version: 1.0 In-Reply-To: <68D8247F-256A-4E0B-9DD5-B7B7C11B87D9@uga.edu> References: <68D8247F-256A-4E0B-9DD5-B7B7C11B87D9@uga.edu> Date: Fri, 16 Sep 2011 10:17:42 -0700 Message-ID: Subject: Re: SIGINT/TRAPINT Behaves Differently in 4.3.11 From: Bart Schaefer To: zsh-workers@zsh.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 15, 2011 at 7:35 PM, wrote: > > I have the following call tree: function prompt_theme_precmd() -> functio= n git-info() -> SUBSHELL -> function git() -> =A0hub -> Git. > > On ZSH 4.3.10, pressing CTRL + C while the above is executing calls the s= hell's TRAPINT function, which is the expected behaviour, but since 4.3.11,= SIGINT is sent only to the executing process (Git), and the shell's TRAPIN= T function is no longer called. > > However, pressing CTRL + C AFTER the prompt has been displayed calls TRAP= INT. > > Is this a bug, or is this the new expected behaviour? This may be related to zsh-workers/27169 and the related (extensive) thread wherein on some platforms the shell was actually exiting on a SIGINT received by a child process. As you might be able to discern from that thread, among other things it was never obvious whether some of those changes should have been restricted to particular #ifdef block. Or it might not be related to that at all. In any case the signal was likely never actually sent to the shell, it was instead reacting to the exit status of whatever process did get the signal. Possibly the issue here is that now the intervening subshell is not propagating interrupt via its exit status up to the parent shell.