Re: programming with pty(4)

[christos%zoulas.com@localhost (Christos Zoulas)]

On Jun 1,  9:05am, brook%nmsu.edu@localhost (Brook Milligan) wrote:
-- Subject: Re: programming with pty(4)

| Christos,
| 
| On Fri, 1 Jun 2012 08:28:49 -0400
| Christos Zoulas <christos%zoulas.com@localhost> wrote:
| 
| > Make sure you close all the file descriptors, or use revoke(2) on the
| > pty.
| 
| Thanks.  Perhaps I am misunderstanding revoke(2).  It sounds like that
| is something I should be doing after I use openpty(3) so that the
| initial connection will not be confused with any prior ones.  However,
| my problem is not with the first connection; that works fine.  The
| problem is after a connection is made with tip(1) and disconnected with
| '~^D' then a subsequent connection fails (unless done by root).

On the server process side you need to detect that the slave closed, and
close the master. If you revoke(2) after you openpty(3) you are not going
to be able to use the pty. revoke(2) was designed pre-openpty, and it was
meant to be called after scanning the list of pty's and before opening it.

| If I am to do another revoke(2) call, when should I do that?  How will
| I know that the first connection has been disconnected?  If I just
| timeout after inactivity will the fact that the slave side of the
| pty(4) disappears create problems for clients that were just inactive
| but still connected?

If you use ptyfs, then you can check in /dev/pts that the pty is closed
because it will dissappear, you can probably also use fstat for the old
style ptys.

christos