Controlling an external program with Python

[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.)

Exporting all lowlevel calls to Python and letting the pty lib take care of
determining which are appropriate creates a horrible mess. I did it with the
new pty lib, that switches between os.openpty, sgi._getpty and the original
BSD 'try and get a tty' methods, and it blows chunks, especially if you take
into account that one method might be available but fail, but another might
succeed.

If there was one 'openpty' call in the os module, which might be emulated
from other kinds of calls in C, for whatever platform it is convenient, most
of what remains are #ifdefs (of which the posixmodule, for one, already has
quite a bunch) and the choice between os.openpty() and opening /dev/pty*
manually.

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.

Both methods of returning a pty can emulate the other just as well; in fact,
the new pty lib does just that ;) it has the old master_open() and
slave_open(), and it has openpty().

I agree, though, that keeping forkpty() in the posixmodule might not be
worth it. It's badly documented, for instance on wether or not the new child
is a session leader or not, so it might end up much easier just using a
python version that utilizes pty.openpty(), and *is* properly documented.

>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.

I'm not sure if 'POSIX defines it' is a criterium for adding a function to
the posix module, though it might be. In that case, it should be factored
out to a _pty module, together with things such as ttyname() possibly. But
I'm not sure if it's out of place in the posix module: Adding it to
posixmodule adds it to the os module, which means that other platforms can
write their own, entirely seperate implementation, without the need to add
more #ifdefs.

>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.

Agreed. I do like the idea of an external, extensive pty-emulation library
or such, but I have two very simple problems with that: I do not have the
time to write it, and I do not have a need for it ;) openpty() is exactly
what I need. I'd be happy to move sgi._getpty into openpty() (if the sgi
module is indeed going to be deprecated/removed) and add other variants, as
a bunch of #ifdefs, but I don't feel like supporting non-UNIX operating
systems, and I don't feel like building an external project for this ;)

Besides, it's late, I shouldn't be posting at this hour :-P

Note-my-crafty-and-elegant-way-of-avoiding-Pythons-version-number<wink>-ly
	y'rs, Thomas.