From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: 0.96b PL2 Pty's broken? Date: Sun, 28 Jun 1992 04:11:56 GMT
dgraham@bmers30.bnr.ca (Douglas Graham) writes:
: Was there a reason why the following patch was applied to the read_chan
: code in 0.96b PL2? Now, a "cat /dev/ttyp0" will return immediately after
: having read 0 bytes, instead of hanging waiting for something to be
: written to the master side. Among other things, this breaks "script".
: ----
:
: *** tty_io.c.pl1 Sat Jun 27 15:24:12 1992
: --- tty_io.c Sat Jun 27 15:35:19 1992
: ***************
: *** 298,303 ****
: --- 290,297 ----
: break;
: if (IS_A_PTY_SLAVE(channel) && C_HUP(other_tty))
: break;
: + if (other_tty && !other_tty->count)
: + break;
: interruptible_sleep_on(&tty->secondary->proc_list);
: sti();
: TTY_READ_FLUSH(tty);
Hmm. I guess this is my fault. I sent linus a patch to correct one
aspect of pty behaviour and it looks like it broke another.
My patch was so that if you read from a pty master after the pty slave
was closed it immediately returns with 0. (This is correct). Here is
what I don't know:
What happens when a read is done on a pty slave without a master? What
should it return, or should it block untill the master is opened. My
GUESS is that it should block.
What should happen when a pty master is read from with a pty slave being
opened. Not after the slave has closed, but before the slave is opened??
Should it block? or return 0 immediately.
What happens with writes in all cases??
Here are some know bugs in the current pty implementation:
1) If should NOT be possible to acquire a pty master as your controlling
terminal. In fact, pty masters should not be terminals at all. They
should behave more like named pipes or sockets.
2) Most, if not all, of he ioctl's aren't implemented.
The documentation I have on pty's is VERY scanty. Does any one have
more information on how these should work? I am very happy to fix it, I
just need to know what it should do.
Michael