Date: Wed, 11 Feb 1998 07:46:22 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sh jobs.c Message-ID: <199802102046.HAA21731@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802102046.HAA21731>