Controlling an external program with Python

[Donn Cave]

Quoth thomas at xs4all.nl (Thomas Wouters):
| On 28 Jun 2000 18:13:39 GMT, Donn Cave <donn at u.washington.edu> wrote:
|> The MIT Kerberos 5 pty library I mentioned uses a getpty function that
|> opens the master pseudoty and returns its file descriptor and the name
|> of its slave terminal device.  Where it uses openpty() underneath, it
|> doesn't supply any termios settings and closes the slave file descriptor
|> immediately.  It doesn't use forkpty() for anything.  My reflex reaction
|> is that's the right level of support for a C module:  export all possible
|> semi-standard low level interfaces, and put convenience routines in a
|> Python module.
|
| I disagree, and I think some of the Python developers do, too, looking at
| the way posixmodule is laid out (and the fact that the SGI module is
| candidate for removal in the next Python release.)

No way did I mean to call for more things like the sgi module.  The kind
of semi-standard operations I have in mind are like termios, for example -
we already have a termios module, so avoid the termios option in openpty -
and then some abstraction of the characteristic operations performed on
pseudotty devices.  Here's how MIT sorts this out:

    long pty_init(void);
    long pty_getpty ( int *fd, char *slave, int slavelength);
    long pty_open_slave (const char *slave, int *fd);
    long pty_open_ctty (const char *slave, int *fd);
    long pty_initialize_slave ( int fd);
    long pty_update_utmp (int process_type,int pid,  char *user,
                          char *line, char *host, int flags);
    long pty_logwtmp (char *tty, char * user, char *host);
    long pty_cleanup(char *slave, int pid, int update_utmp);

Cleanup, for example, performs various platform-specific functions
like revoke() that have to do with shutting down and hanging up the tty.

But whatever functions are provided should certainly be the same for all
platforms inasmuch as possible, not like the way pty.py does it today.

The big head-scratcher for me is MS Windows.  Apparently it would be
possible to support some similar functionality, but obviously from
a completely different implementation.  It would be terrific if the
API were a comfortable fit for Windows too, but that might have to
occur at a much higher level of abstraction, so to speak.

| My reason for taking openpty, which returns an opened master/slave fd pair,
| over something a little more sgi-like (open master, return master_fd + name
| of slave tty) is very simple, and very selfish: I work mostly with BSDI
| servers, FreeBSD and Linux workstations. All support openpty. And the fact
| that Linux has it makes me believe it's the most used method of getting a
| pty.

You could be right about openpty's coverage.  It's in the man pages on
Digital UNIX too.  I don't know exactly why MIT chose to close the
slave tty from openpty(), instead of opening it after ptsname() etc.
to support an openpty-like function.  There might be no particular
reason, but I defer to their accumulated expertise, since they manage
to support telnet and rlogin on a reasonable range of platforms with
this stuff.

	Donn Cave, donn at oz.net