From owner-cvs-bin Fri Feb 6 17:20:23 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08041 for cvs-bin-outgoing; Fri, 6 Feb 1998 17:20:23 -0800 (PST) (envelope-from owner-cvs-bin) Received: from cons.org (knight.cons.org [194.233.237.86]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08006; Fri, 6 Feb 1998 17:20:07 -0800 (PST) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.5/8.7.3) id CAA19537; Sat, 7 Feb 1998 02:21:30 +0100 (CET) Message-ID: <19980207022127.48731@cons.org> Date: Sat, 7 Feb 1998 02:21:27 +0100 From: Martin Cracauer To: Bruce Evans Cc: cracauer@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-bin@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sh jobs.c References: <199802061928.GAA07506@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199802061928.GAA07506@godzilla.zeta.org.au>; from Bruce Evans on Sat, Feb 07, 1998 at 06:28:44AM +1100 Sender: owner-cvs-bin@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I thought we were still discussing it. I didn't like it before, and > like it less now. The committed version has the following bugs: I backed it out. > 1) SIGINT/SIGQUIT are not restored after fork failure. That just needs if (oldsigs_valid) { signal(SIGQUIT,oldsigquit); signal(SIGINT,oldsigint); oldsigs_valid = 0; } in the (pid == -1) clause. > 2) SIGINT/SIGQUIT are always reset to SIG_DFL in the child. This is > wrong if these signals are ignored on entry to the shell. Under what circumstances will a child be entered with ignored signals? One use I can think of is spawning subshells in a shellscript. If signals are always resetted to default, subshells will be exited at once and the whole shellscript will be terminated on one. This is also what bash and pdksh do. So below for an example. I don't think ignoring signals is useful for any fork() that is to be followed by exec(). Everything else is a subshell and therefore part of the script which should exit as a whole on the first SIGINT. > 3) SIGTERM apparently needs to be handled like SIGINT/SIGQUIT. bash > seems to handle it like that. SIGTERM is a different matter. What I'm trying to fix are characters that can be generated from a terminal keyboard and will therefore be used for asynchronous actions by applications. > I'm testing the following fix: [diff ommited] Two test cases where your and my solutions differ: 1) #!/usr/src/bin/sh.work/sh emacs -nw while `true` ; do foo=1 ; done After emacs exits, your version exits the loop only on SIGINT. SIGQUIT and SIGTERM are ignored. My solution exits on all three signals. 2) #!/usr/src/bin/sh.work/sh ( ( emacs -nw while `true` ; do foo=1 ; done ) while `true` ; do foo=1 ; done ) while `true` ; do foo=1 ; done After exiting emacs, my version drops out of all subshells and terminate the whole script on one SIGINT, which I think is the right thing to do. Your version needs three to exit the script. As I said, bash and pdksh need only one as well. And your version ignores both SIGQUIT and SIGTERM, which probably isn't intended. I also managed to bring you version into endless sh in malloc(): warning: recursive call. several by sending mixed signals, but I can't remember the exact sequence for now, sorry. I know that my solution is ugly, but it so far it does what I think is the right thing in all cases. 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