Since a python version of 'expect' is not immediately forthcoming, as
yet, i'm giving in and putting together a 'subprocess' class, based on
one posted a while back by jose pereira. I'm having a weird problem
with using 'select' to poll the pipes connecting to the subprocess. I
put together the following little module, 'prob.py', in order to
exhibit the problem in as succinct a way as i could muster.
I'm no expert on using select, so i can't be very confident that i'm
using it properly. However, the python interface to it, in
particular, appears fairly simple, and i suspect my problem has to do
with the select implementation. Still, i would not be surprised if
i'm misapprehending something, and corrections are quite welcome.
-=- -=V=- -=-
"""prob.py - succinct example demonstrating pipe IO select problem.
ken.manheimer@nist.gov, 10-Jan-1995."""
import sys, os, select
rf, wf = os.pipe()
rfp = os.fdopen(rf, 'r'); wfp = os.fdopen(wf, 'w')
wfp.write('the\n'); wfp.write('spanish\n'); wfp.write('inquisition\n')
wfp.flush()
print 'Pipe primed with three lines written.'
for i in range(3):
print 'Select on read handle:', select.select([rfp], [],[], 0)[0]
print '... and read yeilds:', rfp.readline()[:-1]
-=- -=^=- -=-
What i believe *ought* to be happening in the loop is that the select
should be returning the read file-descriptor every time through, but
it only does so before the first read. All the reads, even those
following empty select returns, each yield one of the three lines with
which the pipe was primed.
Here is a transcript of a run:
-=- -=V=- -=-
>>> import prob
Pipe primed with three lines written.
Select on read handle: [<open file '(fdopen)', mode 'r' at 1469b0>]
... and read yeilds: the
Select on read handle: []
... and read yeilds: spanish
Select on read handle: []
... and read yeilds: inquisition
<module 'prob'>
>>>
-=- -=^=- -=-
This occurs on my solaris 1.1.1 and 2.3 systems, both running the same
versions of python 1.1.1 compiled under solaris 1.1.1, both with and
without guido's import mods.
Anyone have any clues as to what may be happening here???
Thanks,
Ken
ken.manheimer@nist.gov, 301 975-3539