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