Controlling an external program with Python

Thomas Wouters thomas at xs4all.nl
Wed Jun 28 02:29:14 EDT 2000


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

And-I-promise-not-to-run-away-screaming-ly y'rs,
	Thomas.



More information about the Python-list mailing list