From owner-cvs-all Thu Feb 5 23:24:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16214 for cvs-all-outgoing; Thu, 5 Feb 1998 23:24:29 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from cons.org (knight.cons.org [194.233.237.86]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA16186 for ; Thu, 5 Feb 1998 23:24:26 -0800 (PST) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.5/8.7.3) id IAA17464; Fri, 6 Feb 1998 08:25:02 +0100 (CET) Message-ID: <19980206082458.10855@cons.org> Date: Fri, 6 Feb 1998 08:24:58 +0100 From: Martin Cracauer To: Bruce Evans Cc: cracauer@cons.org, cvs-commiters@FreeBSD.ORG Subject: Re: Please review fix for /bin/sh SIGQUIT/SIGINT problem References: <199802052234.JAA25791@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199802052234.JAA25791@godzilla.zeta.org.au>; from Bruce Evans on Fri, Feb 06, 1998 at 09:34:39AM +1100 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe cvs-all" In <199802052234.JAA25791@godzilla.zeta.org.au>, Bruce Evans wrote: > >This diff fixes interactive shells in the case of background jobs. Any > >more special case? > > I don't think this is right. I didn't mean I fixed sh's behaviour. What I meant was that my first fix version accidentially messed with interactive behaviour and that I changed the fix to keep this intact. > Your fix makes the nesting of the signal handling hard to follow and > not obviously correct. I agree that I obfuscate signal handling even more. But the original sh code ignores so many important cases that I felt inserting my own flow of signal handling to correct some obmissions is appropriate. > forkshell() leaves signals "off" and depends > on waitforjob() to turn them "on" again by restoring the signal state. > There are other calls to waitforjob()... Yes, but my fix changes behaviour only for foreground processes. I think in the foreground process case I can assume that the next waitforjob() call is the one that belongs to the forkshell() call. waitforjob() restores my saved signals only when my code changed them before. I did some more testing of my solution (job control with SIGINT/SOGQUIT - catching processes, some more test with subshells) and it still seems to be solid. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer cracauer@wavehh.hanse.de (batched, preferred for large mails) Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715 Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany