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