From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24202 invoked by alias); 19 Feb 2017 00:39:56 -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: 40573 Received: (qmail 27757 invoked from network); 19 Feb 2017 00:39:56 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(0.5/5.0):. Processed in 1.743897 secs); 19 Feb 2017 00:39:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=gU4i=2A=brasslantern.com=schaefer@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at bounces.park01.gkg.net does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=48SljK1ntBgwkTjx4TxTn4z79NHzsah4qJSlkDxoxVE=; b=NH1TkHdSAOwWuy98tvpkZFnUhnJccFaQBcPcOl/loHO7W+l0WeS/cpqbPst0gTZBr5 aAQ3kkSpowBUT3sLOL+oWwkF4vrfhsxCjfbCSmLAx67BHSfXofDP7/jhvTtIEAMO4czo kf6PzMtTN9ppMmvxSQpaUWPiesZiGus5agblBHpLRp1WgSFSLv6yEYd43KWN1rK1D2Tj ZZthdfuRZUAzIen3wThTM7RFJCVfCkWGNnI5xMCccZA//XT75l/NcZb/7hMP+0JdgcLz HLdhItUgw+4WEuF5uyub51jIHAtqKYSl/RKVkh4kDcO2IucB9iBl+JzkAPlrCzrig+/v XoWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=48SljK1ntBgwkTjx4TxTn4z79NHzsah4qJSlkDxoxVE=; b=GrN6abih8MYURhnJXIQVpJAgJet4J7oZnRNJH+4Plp0Qk3zczXNESF62sslAWh2imk Nkstfirw+ZlpGGDXw08tnGL9Rz4HJTQzxEkHll+yOn1ViIXTrY/VE7bThkZwtyxsHPD+ NMyngslBnUNUI+a1h1rfMIYtcpuROXmDTdKAZkflAbJ9kEv10t2dTYq+Sda2yAT40Av2 vCDCJdG8GbYGi7RfYOW1cjlEfrLonxxErh2QbKnSNQ4S/QbhtOgimSv9RzeDHcMykhVg t46PHUiWEP/PF2/vef/U/dPor8aGOjSz+2XfZOn73i8eJjDQQXDqtZVgr4iB9legJgmR KerQ== X-Gm-Message-State: AMke39mLADNBHVGaSSpN1lSNMA3Mfz0Poqa24y+83gsH3gk62ZpmZXQ9a1MiX/NOmbYJXg== X-Received: by 10.31.254.198 with SMTP id l189mr7085488vki.86.1487464761553; Sat, 18 Feb 2017 16:39:21 -0800 (PST) From: Bart Schaefer Message-Id: <170218163919.ZM10641@torch.brasslantern.com> Date: Sat, 18 Feb 2017 16:39:19 -0800 In-Reply-To: <170217120219.ZM11847@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: exec'ing $0 in traps" (Feb 17, 12:02pm) References: <20170217081604.GA59728@bali> <170217120219.ZM11847@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Andre Albsmeier , zsh-workers@zsh.org Subject: Re: exec'ing $0 in traps MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 17, 12:02pm, Bart Schaefer wrote: } } Some combination of the "read" builtin plus calling "exec" from inside } the signal handler is causing the HUP signal to remain blocked across } the "exec" -- and re-installing the trap doesn't unblock it. This affects any process started from a trap -- because the signal handler blocks the signal while it executes, all childred spawned or exec'd during the trap will have the trap signal blocked. E.g. try this in each of bash and zsh: trap 'echo can I interrupt this sleep\?; sleep 10' INT In bash, two interrupts will print the message and kill the sleep. In zsh, the message is printed but sleep is immune to interrupts. However, in both zsh and bash trap 'trap "" INT; echo cannot interrupt: sleep 10' INT result in an uninterruptible sleep after the first interrupt, so it is also not sufficient to always unblock the signal on execve. Note this is independent of what signal is used for the trap, I've reproduced it with HUP, INT, and USR1. Cleaning all this up seems like something entersubsh() should handle; proposed patch for that is the first hunk below. At the same time, install_handler() does not unblock the signal for which the trap is being created. This is a lot trickier, because it isn't clear that trap 'echo "in trap"; trap "echo reset trap" INT; sleep 2' INT is supposed to immediately re-enable HUPs for the parent shell. In bash the new signal handler does not run when the sleep is interrupted but does run subsequently when the parent is interrupted again. Second hunk below is what I *believe* should cover this, but I'm not very certain. Other eyeballs? diff --git a/Src/exec.c b/Src/exec.c index 8f4969f..5b9f8d0 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -1068,6 +1068,17 @@ entersubsh(int flags) } if (!(sigtrapped[SIGQUIT] & ZSIG_IGNORED)) signal_default(SIGQUIT); + /* + * sigtrapped[sig] == ZSIG_IGNORED for signals that remain ignored, + * but other trapped signals are temporarily blocked when intrap, + * and must be unblocked before continuing into the subshell. This + * is orthogonal to what the default handler for the signal may be. + */ + for (sig = 0; sig < VSIGCOUNT; sig++) + if (intrap && sigtrapped[sig] && + sigtrapped[sig] != ZSIG_IGNORED && + sig != SIGDEBUG && sig != SIGZERR) + signal_unblock(signal_mask(sig)); if (!job_control_ok) opts[MONITOR] = 0; opts[USEZLE] = 0; diff --git a/Src/signals.c b/Src/signals.c index a717677..c1604e3 100644 --- a/Src/signals.c +++ b/Src/signals.c @@ -151,6 +151,10 @@ install_handler(int sig) # endif /* SYSV_SIGNALS */ # endif /* BSD_SIGNALS */ #endif /* POSIX_SIGNALS */ + + /* ZSIG_IGNORED is OR'd into sigtrapped[sig] while trap in progress */ + if (!(sigtrapped[sig] & ZSIG_IGNORED)) + signal_unblock(signal_mask(sig)); } /* enable ^C interrupts */