Interfacing with terminal programs

[Donn Cave]

Quoth drifty at bigfoot.com (Drifty):
| I volunteer at the Open Computing Facility at UC Berkeley
| (www.ocf.berkeley.edu) and I am trying to help automate the changing
| of user's passwords.  We currently have to run two separate
| terminal-based programs to change a password and then document the
| change in a log file.  The problem is that I can't figure out how to
| get Python to interface with the terminal program without deadlocking.
| I tried using popen2 but it deadlocks when I read from the output fd.
| I would get away with just using the input fd if I could, but I have
| to make sure the staffer entered their password properly and so I have
| to check to see if it prompted for the password of the staffer again
| or  is ready to take the new password for the user.  I assume the
| deadlock is caused because of the prompt from the terminal program
| isn't letting the output fd know it reached the end of the read.

I'm not sure what you mean by that.  The usual problem, when you
run a program on a pair of pipes, is that the program's output is
block buffered when the device is a pipe, and the output you're
waiting to read is still in that buffer.  A prompt is a bit less
likely to have this problem, because in the normal tty context
where output is line buffered, you have to explicitly flush output
from the buffer to get a prompt.  Ptys solve the buffering problem.
The stderr stream is usually unbuffered, so it will come right out -
but not to the output pipe, if they prompt on stderr.

Anyway, the other problem that will come up with a password prompt
is the tty ioctl that turns off echo.  That will fail on the pipe,
which doesn't support tty ioctls.  The passwd program should abort
at that point.  Ptys solve this problem too.

| Any suggestions?  This has to run on Solaris, so using something like
| pty is obviously iffy.

I think pty is the only thing that can work.  Look for posix.openpty.
You'll have to fiddle around with it, ptys are odd devices that are
a little more trouble to work with.

	Donn Cave, donn at oz.net