jdb@mordor.UUCP (John Bruner) (09/19/85)
When either of the 4.2BSD programs "uw" (the server) or "uwtool"
create a new window, they open a pseudo-terminal and attach a
new process to the "slave" side. The intent is that the
pseudo-terminal will be made the controlling terminal of this
new process. However, due to a error in the sequence that both
programs use to allocate the pseudo-terminal and attach the
process, the resulting process has NO controlling terminal.
This means that keyboard-generated signals such as interrupts
and stops will not be handled correctly.
This bug does not exhibit itself if the new process is "csh".
[The reason really isn't an appropriate topic for discussion
in this newsgroup, but for any UNIX wizards out there I'll give
you a hint: when "csh" (unconditionally) changes the line
discipline to NTTYDISC the kernel routine ttyopen() is called.]
To demonstrate the bug, run "uwtool sh" and then "ps x". The
shell will be listed with no controlling terminal ("?").
This bug only affects the versions of "uw.c" and "uwtool.c" that
I posted in mid-August. (If your source includes "openpty.c"
and "openpty.h", then your copy has the bug. The older version
that I posted in July does not have this problem.)
The easiest bug fix is to add the line
(void)close(open(pt.pt_tname, 0));
after the line
(void)ioctl(open("/dev/tty", 2), (int)TIOCNOTTY, (char *)0);
in both "uw.c" and "uwtool.c".
--
John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758
UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb