Interfacing with terminal programs

[Donn Cave]

Quoth drifty at bigfoot.com (Drifty):
| I decided to give your suggestion a go, Donn, and I had an unexpecting
| surprise.  The command that we are running is 'sudo nispassword
| <username>'.  I decided to try popen2 to get the file objects and then
| use your suggestion of the fd to read from it.  But when I read from
| it the prompt output straight to the screen when all I was doing was
| write the output to a variable.  I have no clue why it output to the
| screen, but it did.

Nor do I.  That sounds like only a few lines of code, so at some point
if you still want to pursue this on c.l.p, it would be a good idea to
include a few lines of Python that demonstrate the problem.  But my
first guess would be that it's not your code, sudo's prompt actually
does not go to stdout, but rather to stderr, and you didn't really
cause this with the file object to fd change but rather changed
something somewhere else.  If so, you would have to use popen3(),
or make your own Popen3 subclass that dups unit 2 -
     os.dup2(c2pwrite, 1)
 --> os.dup2(c2pwrite, 2)  # add this line.

popen3 exposes you to the peril of a deadlock if you read the wrong
pipe, but you can solve that with select.select().

| I can't try a pty either since they are apparently broken on our
| current install.  I am hoping that when I install Python 2.1 that it
| will fix that and I can see what is causing the problem.

I have never had to deal with Solaris, but if posix.openpty() doesn't
work in 2.0, I would guess it won't in 2.1 either.  Pty support in
the posix module is pretty much limited to platforms that support the
openpty() API.  That covers a lot of ground, and past that lies an
endless quagmire - see the C code that handles it in Expect, if you
go that way, and you'll see what I mean by that.

	Donn Cave, donn at u.washington.edu