Hello
I have written a program that interacts with a
command line program.
Roughly speaking, it mimics human interaction.
(With more speed and accuracy, less intelligence.)
It works fine under Linux, using select().
But Windows does not support select for files.
Only for sockets.
Here's a google search on this topic.
<http://groups.google.co.uk/groups?q=select+windows+non-blocking&hl=en&lr=&group=comp.lang.python&scoring=d&start=0&sa=N>
I'd like my program to work under Windows also.
I'm exploring the following approach.
stdin, stdout = os.popen2('tex')
Now read a byte at a time from stdout.
Whenever a prompt string from TeX appears,
write the response to stdin.
An experiment at the Python command line shows
that this works. At each step either
a) we can read one byte from stdout w/o blocking
or
b) we can usefully write to stdin.
By the way, this experiment is rather tedious.
Still, I hope to have my computer do this for me.
So, unless I'm mistaken, I can get the program to
work under Windows. Though reading a byte at a
time might give a performance penalty. Can't say
yet on that.
My question is this: Under Windows, is it possible
to read as many bytes as are available from stdout,
without blocking?
This is one way to improve performance. (If needed.)
Another way, is to use _longer_ prompt strings.
If prompt strings are at least 64 bytes long, then
we can safely read 64 bytes -- unless we are in
the process of reading what might be a prompt
string.
This will of course increase performance in the
limiting case of when there are zero prompt
strings, and expensive system calls.
This problem of non-blocking input on Windows seems
to arise often. I hope my remarks might be helpful
to others. Certainly, I've found it helpful to
write them.
--
Jonathan
http://www.pytex.org
--
http://mail.python.org/mailman/listinfo/python-list
