From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: BUG in 0.99-p5 ??? Date: 16 Feb 1993 00:47:44 GMT
Rick Sladkey (jrs@world.std.com) wrote:
: Michael> Woah!!!! This is NOT a mistake. You should never be able to
: Michael> aquire a pty MASTER as a controlling tty. Only slaves. The
: Michael> master device is NOT a tty. If the program breaks with the
: Michael> correct behaviour, then the program is broken, not linux.
:
: I agree with you on first principles, however in the name of
: compatibility I think we should allow it. I don't know who disallowed
: it (probably Ted?) or why but it breaks rlogin and the comments in
: rlogin indicate that BSD allows it. Don't ask me why.
:
: >From rlogind.c:protocol():
:
: +-----
: | /*
: | * Must ignore SIGTTOU, otherwise we'll stop
: | * when we try and set slave pty's window shape
: | * (our controlling tty is the master pty).
: | */
: +-----
:
: Perhaps we must give up BSD compatibility in this case?
: The alternative is messy but not impossible.
Well, you got me interested enough to go looking.
From what I can see, the controlling tty is actually the SLAVE side of
the pty.
If you look thru the code, it finds a spare master pty, then opens
the slave pty. Then it forks, and exec's a shell.
The curcial point, is the it never changes the controlling tty after
it fork()'s. So the shell has the same ctty as rlogind. Therefore,
rlogind must have the ctty of the slave. I am just about to go look
in the net-0.2 code to see why it is broken, but I can say for sure,
that it isn't the kernels problem. (rlogind opens both the master AND
slave in the parent process).
The best I can see is that the comment is either misleading, or wrong.
Anyone else want to jump in on this??
(The code I used, was that printed in "Unix Network Programming" by
W.R. Stevens. ).
Michael