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-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-AuditID: cbfec7f4-f79026d00000418a-c4-56dea2a806e2 Date: Tue, 08 Mar 2016 10:00:04 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Signal handling bugaboo in command substitution Message-id: <20160308100004.3011d110@pwslap01u.europe.root.pri> In-reply-to: <160307184406.ZM23121@torch.brasslantern.com> References: <160307184406.ZM23121@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsVy+t/xK7orFt0LM1g0ldPiYPNDJgdGj1UH PzAFMEZx2aSk5mSWpRbp2yVwZUyc/ZKxoImv4ut0/gbGN1xdjJwcEgImEl/eHWaBsMUkLtxb z9bFyMUhJLCUUWL3txYWCGcGk8Td59vBqoQETjNKrN+YApE4wyjxessKVpAEi4CqxINbG9lA bDYBQ4mpm2YzgtgiAuISZ9eeB2sWFrCR2HB1CjOIzStgLzHh4TEmEJtTwEri7/cudogFlhLH +nrBZvIL6Etc/fuJCeI8e4mZV84wQvQKSvyYfA9sJrOAlsTmbU2sELa8xOY1b5kh5qhL3Li7 m30Co/AsJC2zkLTMQtKygJF5FaNoamlyQXFSeq6hXnFibnFpXrpecn7uJkZIMH/Zwbj4mNUh RgEORiUe3o7vd8OEWBPLiitzDzFKcDArifCWLrwXJsSbklhZlVqUH19UmpNafIhRmoNFSZx3 7q73IUIC6YklqdmpqQWpRTBZJg5OqQZGH8MFKuqq8jwJ5SGTXyqp9X/U9jP5b7d955pfD+ey rJu/9Vnpine3J1a+Faro/NTM6v62KXfh61U7PHzKnDaoPkgPu/DoQpyn2Ty1j0Heh1t1anr6 nhwOdTG7/l4h6Ov2q8eu7JETdKs7PENKY9OsLVXHTjxN2vo+9phM5FyjzMXXe0/eSfj7Qoml OCPRUIu5qDgRAGN4TaJiAgAA X-Seq: zsh-workers 38113 On Mon, 07 Mar 2016 18:44:06 -0800 Bart Schaefer wrote: > At a PS1 prompt: > > torch% print $(sleep 3; echo foo) > > Press ctrl+z during the sleep. Zsh is now hung, because the command > substitution is occuring in prefork() so there's nothing to handle the > stopped children and the parent itself ignores the signal. Zsh is hung; > it won't return to a prompt, the command substitution will never produce > the awaited output, and nothing (except "kill -CONT" from another shell) > will wake it back up. > > I'm not sure what to do here. In other circumstances it's OK to stop a > command substitution with a ctrl+z, and in any kind of non-interactive > shell or even in a subshell the parent would handle the signal. > > Bash appears to leave TSTP blocked here when interactive. I don't think > testing for interactivity is sufficient in zsh context, though. How about something like this? pws diff --git a/Src/exec.c b/Src/exec.c index b60fc90..caeb461 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -1001,9 +1001,21 @@ entersubsh(int flags) * signals. If it is, we need to keep the special behaviour: * see note about attachtty() above. */ - signal_default(SIGTTOU); - signal_default(SIGTTIN); - signal_default(SIGTSTP); + if (flags & ESUB_NOMONITOR) + { + /* + * Allowing any form of interactive signalling here is + * actively harmful as we are in a context where there is no + * control over the process. + */ + signal_ignore(SIGTTOU); + signal_ignore(SIGTTIN); + signal_ignore(SIGTSTP); + } else { + signal_default(SIGTTOU); + signal_default(SIGTTIN); + signal_default(SIGTSTP); + } } if (interact) { signal_default(SIGTERM);