Controlling an external program with Python

[Donn Cave]

Quoth thomas at xs4all.nl (Thomas Wouters):
|>| In unix, AFAIK the only nonportable part is the *naming* of the pty
|>| devices. That kind of decision is fairly trivial to make in
|>| sh/awk/perl/python/tcl...
|>
|> The Berkeley pty, with the kind of naming scheme you allude to, is
|> already supported in the "pty" module.  It's supposedly tested on
|> Linux, and I'd expect it could work on FreeBSD/NetBSD/etc., and
|> probably lots of others like Digital UNIX.
|
|> But it's far from universal, and some of the alternatives do use
|> special functions that would need to be supported in C.
|
|> On the bright side, I am optimistic that the horrors of past
|> pseudotty implementations are fading into oblivion and the
|> survivors are fewer and cleaner.
|
| I'd be interested in hearing about some of these pty-implementations. I know
| about the SGI one, for which there is support in the sgi module, and I know
| about openpty() (currently used by at least BSDI, FreeBSD and (glibc
| 2.1-based) Linux) -- in fact I submitted a patch to make the pty module use
| 'openpty()' and 'forkpty()' if it's available. And I know of the old
| BSD/Linux way of 'just opening a pty' of course.
|
| Are there any other 'mainstream' methods of opening a pty ? Could they be
| implemented in terms of openpty() and/or forkpty() ? It would be pretty neat
| if the 'emulation' could stay inside the posixmodule, without the need for X
| different OS-specific modules and Y different function names for each method
| of getting a pty ;)
|
| If someone can send me some manpages/infopages/whatever on 'other methods'
| and be willing to test my code, I'd be happy to add it to the posix/pty
| module.

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.

Some of these interfaces may be appropriate for the posix module, but
I doubt it!  Aside from the narrow-minded question of whether any of it
is covered by POSIX 1003.1, from the user side it's inevitable that on
some platform that does build the posix module, the pty functions won't
be supported.  They'll need another module that can be optionally
supported, like termios, fcntl et al.

The worst mess is that collection of hacks and tricks to open the
slave terminal without security exposure and in a way that allows
features like Berkeley job control to work correctly.  It's a mess
because it's poorly documented and, at least in the case of security,
it deals with gaps rather than features.  Someone will have to sort
those out and incorporate them into a few platform-independent functions
that cover the necessary ground without taking too much onto themselves -
I mean like forkpty() takes too much on itself, in my opinion, to be
something we would want at the C level.

The more we can steal, the better.  There's too much platform specific
folklore in here to write a good C implementation from scratch with
man pages.

	Donn Cave, donn at u.washington.edu