🚀 go-pugleaf

Submitted-by: barmar@think.uucp (Barry Margolin)

In article <16118@cs.utexas.edu> sef@kithrup.COM (Sean Eric Fagan) writes:
>In article <16068@cs.utexas.edu> thorinn@rimfaxe.diku.dk (Lars Henrik Mathiesen) writes:
>>I'd very much hope that such an ioctl would include checks for the
>>termio settings of the slave side: A signal should only be allowed if
>>it would be possible to write a character on the master pty to achieve
>>the same result. (And then, why not do just that?)

>Emacs defines C-xC-c in shell mode to be "interrupt-shell-subjob."  It is
	       ^^^^^^
	       C-cC-C
>defined to send a SIGINT to the process group.  Not a control-c, or DEL, or
>whatever you have your interrupt character defined as.

One problem I've run into with the current implementation is that it has
trouble when I run a setuid program in the shell buffer.  The Emacs process
can't send signals to the setuid process.  I ended up redefining C-cC-c and
C-cC-z to just stuff ^C and ^Z into the pty.

However, your idea of an ioctl to send a signal to the other side of a pty
(I assume that's what this is about, I missed the beginning of the
discussion) seems like it would be just right.  Normal terminal users
sometimes get stuck because a program disables control characters and then
a bug sends it into an infinite loop.  The problem is the multiplexing of
the keyboard for input to the program and process control.  On the other
hand, when a program is being run through a pty there is no need to disable
signals just because the signal *characters* are disabled.  Ioctls provide
the needed out-of-band mechanism for process control that is not available
on a real terminal.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

Volume-Number: Volume 22, Number 38