From owner-freebsd-current Tue Feb 10 12:50:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11368 for current-outgoing; Tue, 10 Feb 1998 12:50:58 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11362 for ; Tue, 10 Feb 1998 12:50:55 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id HAA21731; Wed, 11 Feb 1998 07:46:22 +1100 Date: Wed, 11 Feb 1998 07:46:22 +1100 From: Bruce Evans Message-Id: <199802102046.HAA21731@godzilla.zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org Subject: Re: cvs commit: src/bin/sh jobs.c Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >In my opinion, if the user uses an application that uses SIGINT and >SIGQUIT for its own purposes (that means, using these signals is part >of normal program usage like any other keystroke is), then the >surrounding shell should not take any action based on the signals. No >matter if it is done synchonously or after the childs exits. The >script above should run the cleanup in any case. Apparently, this is supposed to be programmed into the surrounding shell script. >Also, I would like to avoid waking up the shell everytime a signal >arrives. This would be a pessimization according to sh's philosophy. I first objected to your version because I remembered that it goes to some trouble to get woken up at inconvenient time because this is considered better than fiddling with signals. Here is a comment about this. /* * These macros allow the user to suspend the handling of interrupt signals * over a period of time. This is similar to SIGHOLD to or sigblock, but * much more efficient and portable. (But hacking the kernel is so much * more fun than worrying about efficiency and portability. :-)) */ >/bin/csh behaves as you describe, BTW. I added a test for this to my suite. > >> The SIGINT case still works, accidentally, when the foreground command >> is killed by a SIGINT. Then the shell forwards the signal to itself >> after it restores its signal catcher. This can probably be fixed >> by replacing the signal(..., SIG_IGN)'s by a sigprocmask(SIG_BLOCK, >> ...), etc. Signals will be delayed until they are unblocked after the >> command completes, but this is precisely what is wanted. > >Hm, unless I'm convinced otherwise, this isn't what I want. It's fine >in the case that the child is killed by (did not catch) the signal, >though. It's also fine (and required) when the shell is trapping the signal - the trap handler will be reinstalled before the signal is delivered. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message