Controlling an external program with Python

[Donn Cave]

Quoth Alexandre Ferrieux <alexandre.ferrieux at rd.francetelecom.fr>:
| Paul Duffin wrote:
|>> existence of the 'pty' unix package, which is roughly "Expect minus
|>> Tcl", and especially its 'nobuf' tool:
|>>
|>>         nobuf cmd [args...]
|>>
|>> starts cmd as a child, strongly held between ptys, so that the overall
|>> command behaves properly (ie in unbuffered or line-buffered mode) betwen
|>> pipes. If all you want is that, Expect is surely an overkill.
|>>
|> 
|> Where can I get the 'pty' package from ?
|
| Last time I checked it was a pty-4.0.tar.gz .
| I find it currently with FTPSearch at
| ftp://ftp.sunsite.org.uk/Mirrors/wuarchive.wustl.edu/languages/c/unix-c/kernel/pty4.tar.gz
| .
|
| Surely more recent/portable variants must exist...

Not of Dan Bernstein's pty, but the MIT Kerberos 5 implementation
of all things has a portable pty library.  One unfortunate effect
of its association with Kerberos is some really silly export problems.
They appear to have thought about breaking it out, and may already
distribute it in other places, I don't know.

|>> But ptys are no rocket science anyway. The nobuf above should be doable
|>> in pure Python within 20 loc...
|
|> While ptys are not rocket science they are also not particularly portable,
|> Expect handles all of this for you.
|
| 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.  So if you have looked at
Expect's pseudotty support and run away screaming, I think
there is no reason a module written today would have to be
that messy.

|> Windows is also a real problem as it
|> does not have ptys and needs to be approached in a completely 
|> different way.
|
| Yes but Expect for Windows is a totally different distrib too :-(
|
| Hence the suggestion to consider writing a specific Python module (if
| there isn't already - I've just arrived in town): for unix it just opens
| the proper devices and substitutes the popen2() pipes with the masters;
| for windows more trickery is needed (namely, behaving as a debugger to
| trap IO calls!), but should be doable in win32all, shouldn't it ?

Good idea, especially if the author isn't going to run away after a
couple of months and leave it to gather mold.

	Donn Cave, donn at oz.net