Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rochester!daemon From: stuart@rochester.arpa Newsgroups: comp.windows.x Subject: ^C ignored by xterm under /bin/sh, and SOLUTION Message-ID: <533@sol.ARPA> Date: Tue, 14-Jul-87 05:10:07 EDT Article-I.D.: sol.533 Posted: Tue Jul 14 05:10:07 1987 Date-Received: Wed, 15-Jul-87 04:23:05 EDT Sender: daemon@rochester.arpa Lines: 32 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.edu