[Distutils] Python module to: Talk to stdout/stdin for 64-bit Windows/Linux C++ application?
peter.mowry at amd.com
Mon May 14 04:12:15 CEST 2007
The subprocess module doesn't work for interactive programs (I think)
(see appended pexpect faq).
So instead, I was trying to get something like the following working:
import simnow # import complex simnow C++ application
simnow.start() # spawn simnow's main method
output1 = simnow.sendCommand("load platform x") # blocking call to a
single simnow C++ functions
# This is our real current goal, but if I get this working, we might
consider exposing other simnow functionality to the simnow python
disutils is listed in the extend/embed python doc
(http://www.python.org/doc/ext/ext.html). This doc seems to be saying
that disutils is a cross-plaform way to build a python module ("extend
Chapter 3 - disultils cross-platform build. Chapter 4 - do it yourself
windows build. Chapter 5 - do it yourself unix build. Chapter 4 says,
"Module authors are encouraged to use the distutils approach for
building extension modules, instead of the one described in this
subprocess - "appended comments"
# This doesn't work
self.simnow = Popen(executable=(os.getcwd() + '/simnow'),
args=simnowCmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)
Why doesn't it work? The following is from the pexect FAQ
Q: Why not just use a pipe (popen())?
A: A pipe works fine for getting the output to non-interactive programs.
If you just want to get the output from ls, uname, or ping then this
works. Pipes do not work very well for interactive programs and pipes
will almost certainly fail for most applications that ask for passwords
such as telnet, ftp, or ssh.
There are two reasons for this.
First an application may bypass stdout and print directly to its
controlling TTY. Something like SSH will do this when it asks you for a
password. This is why you cannot redirect the password prompt because it
does not go through stdout or stderr.
The second reason is because most applications are built using the C
Standard IO Library (anything that uses #include <stdio.h>). One of the
features of the stdio library is that it buffers all input and output.
Normally output is line buffered when a program is printing to a TTY
(your terminal screen). Everytime the program prints a line-feed the
currently buffered data will get printed to your screen. The problem
comes when you connect a pipe. The stdio library is smart and can tell
that it is printing to a pipe instead of a TTY. In that case it switches
from line buffer mode to block buffered. In this mode the currently
buffered data is flushed when the buffer is full. This causes most
interactive programs to deadlock. Block buffering is more efficient when
writing to disks and pipes. Take the situation where a program prints a
message "Enter your user name:\n" and then waits for you type type
something. In block buffered mode, the stdio library will not put the
message into the pipe even though a linefeed is printed. The result is
that you never receive the message, yet the child application will sit
and wait for you to type a response. Don't confuse the stdio lib's
buffer with the pipe's buffer. The pipe buffer is another area that can
cause problems. You could flush the input side of a pipe, whereas you
have no control over the stdio library buffer.
What's wrong with pexpect? It doesn't work on Windows. Python COM is
an alternative, but we are trying to find a clean unified cross-platform
Peter Mowry ("Pem")
SimNow Team, Software Engineer
From: David Arnold [mailto:david at mantara.com]
Sent: Saturday, May 12, 2007 10:00 PM
To: Mowry, Peter
Cc: distutils-sig at python.org
Subject: Re: [Distutils] Python module to: Talk to stdout/stdin for
64-bit Windows/Linux C++ application?
-->"Peter" == Mowry, Peter <peter.mowry at amd.com> writes:
Peter> My team's application does regressions by controlling our
Peter> 64-bit Windows/Linux C++ application (SimNow,
Peter> www.amd.com/simnow) via stdout/stdin with ("pexpect" for unix)
Peter> and (python COM objects) for Windows (b/c popen doesn't work).
Peter> However, I am trying to replace this with a unified
Peter> windows/linux solution.
have you looked at the subprocess module, part of the standard library
in Python 2.4 and later?
Peter> Does extending python with Disutils sound like the simple and
Peter> clean way for my goal? Is there a simple cookbook solution for
Peter> my goal?
i don't think distutils is what you're after. distutils is about
producing installers for Python applications.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG