stuart@rochester.arpa (07/14/87)
The Bourne shell (/bin/sh) has an annoying property. It always sets
background processes to ignore INT (^C) and QUIT (^\) and when it
initializes, it usually doesn't attempt to restore INT and QUIT
handling. Normally this is not a problem because (a) background shells
are usually not interactive, and (b) most people use the C shell (/bin/csh).
However, when spawning xterms (for example) in the background that are
supposed to exec /bin/sh, the resulting shell (and xterm) will ignore
interrupts both from the keyboard and from the xterm ^right-button
menu. I had this problem in two places: in the /bin/sh script xinit
was carrying out initially, and when a uwm menu action was trying to
fork a new xterm. The following is the action that DOES NOT work as
desired when SHELL == "/bin/sh".
menu = "New Window" {
Local: !"xterm =80x60 -n $DISPLAY -e $SHELL &"
}
Here's my solution, which should be applicable to other window managers
as well as uwm (or any other time you need to put an interactive
/bin/sh in the background). First, I stopped using a /bin/sh script to
create my initial windows. I now use xtools instead, which does not
ignore INT and QUIT before execing. However, the solution to the
second problem will fix the first problem, too. In a menu action, the
following works because /bin/csh attempts to restore INT and QUIT handling
during its initialization.
menu = "New Window" {
Local: !"xterm =80x60 -n $DISPLAY -e /bin/csh -f -c $SHELL &"
}
Stu Friedberg {seismo, allegra}!rochester!stuart stuart@cs.rochester.educhris@COLUMBIA.EDU (Chris Maio) (07/14/87)
What you describe is a bug in xterm, and the fix is simple -- just add signal(SIGINT, SIG_DFL); signal(SIGQUIT, SIG_DFL); after the "signal(SIGTERM, SIG_DFL);" in main.c. Chris
guy%gorodish@Sun.COM (Guy Harris) (07/14/87)
> The Bourne shell (/bin/sh) has an annoying property. It always sets > background processes to ignore INT (^C) and QUIT (^\) and when it > initializes, it usually doesn't attempt to restore INT and QUIT > handling. Umm, to put it bluntly, it doesn't have much choice in the matter when running under a system that doesn't support job control. It has to protect background processes from ^C and ^\ typed at the keyboard somehow; systems without job control tend not to have very convenient facilities for detaching those processes from the terminal's process group (the S5 "setpgrp" is much too drastic, as it detaches the process executing the "setpgrp" from its controlling terminal, and V7 didn't even *have* "setpgrp"). As such, the correct fix is to fix all programs that 1) are really interactive or run interactive shells and 2) are often fired off in the background to restore the signal actions for SIGINT and SIGQUIT themselves. Yes, this is unfortunate, but there's not a lot you can do about it. (Consider that there will be, and probably already are, X implementations on UNIX systems without job control.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com