Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!necntc!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: ^C ignored by xterm under /bin/sh, and SOLUTION
Message-ID: <23416@sun.uucp>
Date: Tue, 14-Jul-87 14:16:16 EDT
Article-I.D.: sun.23416
Posted: Tue Jul 14 14:16:16 1987
Date-Received: Thu, 16-Jul-87 06:49:08 EDT
References: <533@sol.ARPA>
Sender: news@sun.uucp
Lines: 23

> 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