sending input to an embedded application

[norseman]

Matthew Fitzgibbons wrote:
> 
> mefyl wrote:
>> Uwe Schmitt wrote:
>>> On 12 Jul., 09:08, George Oliver <georgeolive... at gmail.com> 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
norseman at hughes.net