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