brooks@lll-crg.UUCP (02/21/87)
We are having a bit of flakyness with ^C in an xterm window. Sometimes the running process, like tail for instance, is crumped properly and sometimes not. Has anyone run into this problem, and if so how did you solve it.
garfinke@hplabsc.UUCP (02/22/87)
A simple workaround would be to put an stty line in your .profile (or whatever ksh uses). Something like: stty intr ^C This seems like the easiest fix to me. Dan Garfinkel (hplabs!garfinkel)
edmoy@opal.berkeley.edu.UUCP (02/22/87)
In article <10978@lll-crg.ARpA> brooks@lll-crg.ARpA (Eugene D. Brooks III) writes: >We are having a bit of flakyness with ^C in an xterm window. >Sometimes the running process, like tail for instance, is >crumped properly and sometimes not. Has anyone run into this >problem, and if so how did you solve it. The only one I know about is if you have a uwm process in background and open a xterm window from the uwm menu. Also, the shell that is started doesn't automatically reset interrupts and quit signals (/bin/sh doesn't while /bin/csh does). This is because the standard uwm process has those signals ignore (because it is backgrounded) and uses a system() call to evec processes, so the ignore signals get passed on. Xterm only resets the hangup signal, so if your shell doesn't fix the interrupt and quit signals, the ignoring gets passed to all spawned processes. I've fixed that in my version of uwm, and I could post it if there is enough interest. Edward Moy Academic Computing Services University of California Berkeley, CA 94720 edmoy@opal.Berkeley.EDU ucbvax!opal!edmoy
chris@COLUMBIA.EDU.UUCP (02/22/87)
Ed, That fix (reseting SIGINT and SIGQUIT) belongs in xterm, not uwm. You don't want random processes started by uwm to start catching ^C's in the window uwm was started in (if it was started from an xterm window), but you do want xterm shells to work regardless of whether the user has hacked on their copy of uwm, right? The Korn shell exhibits the same problem as /bin/sh does. Chris