Matthew Fitzgibbons wrote:
mefyl wrote:
Uwe Schmitt wrote:
On 12 Jul., 09:08, George Oliver <[EMAIL PROTECTED]> wrote:
What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.
Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?
http://sourceforge.net/projects/pexpect/ might help you
Although Pexpect looks more advanced and complete, you might want to
take a
look at popen* modules. It enables you to easily run a subprocess,
feed him
data on stdin, retrieve output from stdout/stderr, and wait for its
completion.
http://docs.python.org/lib/module-popen2.html
I believe the subprocess module is the recommended module to use now.
-Matt
--
http://mail.python.org/mailman/listinfo/python-list
=====================================
HUMMMMMM!
#
print "popen3 run"
########## from existing python docs:
from popen2 import *
r,w,e= popen3('dmesg | grep hda')
print r.read()
print "subprocess run"
########## from existing python docs:
# "... Replacing older functions with the subprocess module..."
from subprocess import *
p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0]
#documentation quits
print p2.communicate()
#
""" Why do children insists on making things more complicated
than necessary? If the stated bragging rights of Python
is that one writes less code to accomplish more, then I
have to say "bullshit", just count the printable characters.
to write less would be to change something like this:
try:
f = open(arg, 'r')
except IOError:
print 'cannot open', arg
else:
print arg, 'has', len(f.readlines()), 'lines'
f.close()
### I have to guess what type error to code for and I'll need another
module to decode what actually went wrong.
to this:
if (fd = os.open(filename, 'O_RDRW|O_BINARY, 0666) == -1)
...handle it
if fd.err.type == THIS #catagory
if fd.err == this #specific
do this
etc.
## just to see what went wrong? print fd.err.type, fd.err
else: #just to match above
continue processing
### error reporting actually usefull
who says fd cannot be simple interger or pointer to error block
depending on whether it's valid or not? The bonus is, if there is
no trap it will stop anyway first time fd is used as a file number.
The crash usually actually points to the correct place. :)
All that aside: subprocess seems to have a problem:
"""
# When I run the above I get:
==============
PY:> py test.py
popen3 run
ide0: BM-DMA at 0x1400-0x1407, BIOS settings: hda:DMA, hdb:pio
hda: ST9160821A, ATA DISK drive
hda: attached ide-disk driver.
hda: host protected area => 1
hda: cannot use LBA48 - capacity reset from 312581808 to 268435456
hda: 268435456 sectors (137439 MB) w/8192KiB Cache, CHS=19457/255/63,
UDMA(100)
hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 >
subprocess run
('', None)
PY:>
=============
Note subprocess yields unexpected answer. Probably needs better
documentation and less typing. :)
The "PY:> " is result of script to change to dir python and set the PATH
py is copy of python renamed to afford less typing. (Unix vs Microsoft)
Note: without lots of extra effort, the piping only works for commands
like grep that are built to accept redirected I/O. I have yet to get it
to work with the GUI type. Those need special things implanted at
compile time because they don't use or even want the command line
interface. Typically they are "Point'n'Click" or take a hike. GUIs are
visually more appealing but don't play well in the production world.
Steve
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
