From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12821 invoked by alias); 8 Mar 2016 10:12:29 -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: 38114 Received: (qmail 11868 invoked from network); 8 Mar 2016 10:12:29 -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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-AuditID: cbfec7f4-f79026d00000418a-1f-56dea588c3fe Date: Tue, 08 Mar 2016 10:12:21 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Signal handling bugaboo in command substitution Message-id: <20160308101221.625cef45@pwslap01u.europe.root.pri> In-reply-to: <20160308100004.3011d110@pwslap01u.europe.root.pri> References: <160307184406.ZM23121@torch.brasslantern.com> <20160308100004.3011d110@pwslap01u.europe.root.pri> 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/xq7odS++FGaw7yGlxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mq4f3MZe8IK74sLNOYwNjCs5uxg5OSQETCSOX+phhLDFJC7c W8/WxcjFISSwlFFiz76X7BDODCaJuV2NTCBVQgKnGSV+/TCGSJxhlFiz+DBYgkVAVWLm7U5W EJtNwFBi6qbZYGNFBMQlzq49zwJiCwvYSGy4OoUZxOYVsJeYu3o2UC8HB6eAg8TSpZYQ8/Ml LqztBCvnF9CXuPr3ExPEdfYSM6+cYYRoFZT4MfkeWA2zgJbE5m1NrBC2vMTmNW+ZIeaoS9y4 u5t9AqPwLCQts5C0zELSsoCReRWjaGppckFxUnquoV5xYm5xaV66XnJ+7iZGSDB/2cG4+JjV IUYBDkYlHt6O73fDhFgTy4orcw8xSnAwK4nwli68FybEm5JYWZValB9fVJqTWnyIUZqDRUmc d+6u9yFCAumJJanZqakFqUUwWSYOTqkGRlPRyUdTvc8pW9s2VD/ev8yrcGFftMc1q+uMm4TP T1AoVnZhs1f7Wt2RqnxGe9lWIbHbDGcbF5etVWN+Zm3iGD+tdGXfJKtpTxjXMa1J6zr+eXvx ooX3Tzmn3uY5IzP/5W/XG7eq+42rGC+7Vettlzj0cc4t08mSH9RyBAtUT0gE5Eo+sXUxVWIp zkg01GIuKk4EAKASonZiAgAA On Tue, 8 Mar 2016 10:00:04 +0000 Peter Stephenson wrote: > How about something like this? Actually, probably ESUB_NOMONITOR should take precedence. That's really not a good place to allow this stuff, no matter who thought it might be... pws diff --git a/ChangeLog b/ChangeLog index 420eb26..ce05a3d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,4 @@ -2016-03-07 Peter Stephenson +-2016-03-07 Peter Stephenson * 38111: Src/parse.c: remove redundant return values from par_list() and par_list1(). diff --git a/Src/exec.c b/Src/exec.c index b60fc90..9fec16e 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -994,9 +994,19 @@ entersubsh(int flags) if ((flags & ESUB_REVERTPGRP) && getpid() == mypgrp) release_pgrp(); shout = NULL; - if (!job_control_ok) { + 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 if (!job_control_ok) { /* - * If this process is not goign to be doing job control, + * If this process is not going to be doing job control, * we don't want to do special things with the corresponding * signals. If it is, we need to keep the special behaviour: * see note about attachtty() above.