From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16001 invoked by alias); 19 Feb 2017 04:42:39 -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: 40576 Received: (qmail 4380 invoked from network); 19 Feb 2017 04:42:39 -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 0.840509 secs); 19 Feb 2017 04:42:39 -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=sXbzhVajRe+CLZQZ3W0NDC/2q43KD19uWthoSTQuyO0=; b=NzLa3z8/WK64We8se0Fs/CVYvPR+9xMu3LeK8FYNgMGWpbsLLViZyqOjLqrKNYYnEb kMyP0EVoVsdf1U5Ow2gPNKjuXp7HxPImoKrA+7yFxX3tUpuxyM361Ii1hkHfq6YVqafX uRxqjqutOXxHu0kMLpe4Ge3BDJbtTDhMzEmA0aUpQsOcGW7qhhLRLYvG97TX9WUftNQo KdN5m6vcOqyGV7H5p7nCTO7+LaAXIet0u4RthHiQDTHxeMWhyCM83O4MCDNk+GQ6fqVC Q8n01d+WefCysQUH62GtyR4EX3vtKMC279BY5wLsgnF9jDBahGjMDUIpgCvZuwlsoZLD 6DjA== 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=sXbzhVajRe+CLZQZ3W0NDC/2q43KD19uWthoSTQuyO0=; b=Bc+bZUMdkK11BklbywfM+AAAQAzHIKC/jzraeYgpD4i191chStaaf1xdtH6VgRtL1y 5JK4dr3kzTLsEZ9BnQqvsDN+yJEeM5R6fmCEqCspSANX9gqi9zfeXtFX+5pjaIrSszey cMAH6CHUHSxOnRAXRCX7ror1/o0ighAz9oOkpe6/Nvtil6hkdOPsexlMxV1Wr2GHXdsj +Yp5Y/F3pvt1YncFwPsi8rSqjBSFo57Mwk1zKfmIMMWOh0fQq6Ijp++RX+Yil7BU8/t4 16FfsTl/1rdaDy3GjJ7KrIf7cM/piZk6yoz1KOEeEeduraDIbfeANvGzmUaXMAr/NXIF h34w== X-Gm-Message-State: AMke39k44YdQ2JBnvIt/E69qoS0yr+cJ2JRXCXxOiQ2YtwTE0Wcugo6vJMkevcVuMk/2xw== X-Received: by 10.31.32.77 with SMTP id g74mr6808047vkg.122.1487479341180; Sat, 18 Feb 2017 20:42:21 -0800 (PST) From: Bart Schaefer Message-Id: <170218204221.ZM26883@torch.brasslantern.com> Date: Sat, 18 Feb 2017 20:42:21 -0800 In-Reply-To: <170218163919.ZM10641@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: exec'ing $0 in traps" (Feb 18, 4:39pm) References: <20170217081604.GA59728@bali> <170217120219.ZM11847@torch.brasslantern.com> <170218163919.ZM10641@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 18, 4:39pm, Bart Schaefer wrote: } } 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. } } Cleaning all this up seems like something entersubsh() should handle; } proposed patch for that is the first hunk below. Better formulation of that follows. } At the same time, install_handler() does not unblock the signal for } which the trap is being created. } } Second hunk below is what I *believe* should cover this, but I'm not } very certain. Other eyeballs? Further testing shows this is wrong -- removetrap() has been called to clear the old trap, so sigtrapped[sig] is always 0 at this point. The globals from signals.c don't reliably identify which signals are being blocked or ignored. However, some testing reveals another difference: (sleep 5 && pkill -USR1 sleep) & (trap "" USR1; exec zsh -fc "trap : USR1; exec sleep 20") For bash [4.2.25], an inner USR1 trap like that does not change ignored state from the parent shell. Zsh (any version up to the current one) restores default handling when adding the inner trap, EXCEPT when using "trap - USR1" in which case the ignored state is preserved. In short I don't know what to do upon setting a trap, so I'm going to leave that for now and settle for fixing the (un)block state in the subshell. diff --git a/Src/exec.c b/Src/exec.c index 8f4969f..aea9d0e 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -975,9 +975,8 @@ entersubsh(int flags) int sig, monitor, job_control_ok; if (!(flags & ESUB_KEEPTRAP)) - for (sig = 0; sig < VSIGCOUNT; sig++) - if (!(sigtrapped[sig] & ZSIG_FUNC) && - sig != SIGDEBUG && sig != SIGZERR) + for (sig = 0; sig < SIGCOUNT; sig++) + if (!(sigtrapped[sig] & ZSIG_FUNC)) unsettrap(sig); monitor = isset(MONITOR); job_control_ok = monitor && (flags & ESUB_JOB_CONTROL) && isset(POSIXJOBS); @@ -1068,6 +1067,18 @@ 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. + * + * Start loop at 1 because 0 is SIGEXIT + */ + for (sig = 1; sig < SIGCOUNT; sig++) + if (intrap && sigtrapped[sig] && + sigtrapped[sig] != ZSIG_IGNORED) + signal_unblock(signal_mask(sig)); if (!job_control_ok) opts[MONITOR] = 0; opts[USEZLE] = 0;