Great reply, I had just mixed Pexpect and subProcess code until I'd got something that worked, you can actually explain my code better a I can myself. I find it quite cumbersome to read stdout/strerr separately, and to be able to write to stdin in reaction to either of them, but at least on Linux you can get it to work. My NON_BLOCKing command might be unnecesary, I'll try without it.
The OP seemed interested on how to do this on Windows, but I've yet to see an answer on that one I think. Thank you for the reply. Adriaan Renting |>>>Donn Cave <[EMAIL PROTECTED]> 09/15/05 6:19 pm >>> |In article <[EMAIL PROTECTED]>, |Peter Hansen <[EMAIL PROTECTED]> wrote: | |>Jacek Pop³awski wrote: |>>Grant Edwards wrote: |>> |>>>On 2005-09-12, Jacek Pop?awski <[EMAIL PROTECTED]> wrote: |>>> |>>>>> ready = select.select(tocheck, [], [], 0.25) ##continues |>>>>>after 0.25s |>>>>> for file in ready[0]: |>>>>> try: |>>>>> text = os.read(file, 1024) |>>>> |>>>> |>>>>How do you know here, that you should read 1024 characters? |>>>>What will happen when output is shorter? |>>> |>>>It will return however much data is available. |>> |>>My tests showed, that it will block. |> |>Not if you use non-blocking sockets, as I believe you are expected to |>when using select(). | |On the contrary, you need non-blocking sockets only if |you don't use select. select waits until a read [write] |would not block - it's like "if dict.has_key(x):" instead of |"try: val = dict[x] ; except KeyError:". I suppose you |knew that, but have read some obscure line of reasoning |that makes non-blocking out to be necessary anyway. |Who knows, but it certainly isn't in this case. | |I don't recall the beginning of this thread, so I'm not sure |if this is the usual wretched exercise of trying to make this |work on both UNIX and Windows, but there are strong signs |of the usual confusion over os.read (a.k.a. posix.read), and |file object read. Let's hopefully forget about Windows for |the moment. | |The above program looks fine to me, but it will not work |reliably if file object read() is substituted for os.read(). |In this case, C library buffering will read more than 1024 |bytes if it can, and then that data will not be visible to |select(), so there's no guarantee it will return in a timely |manner even though the next read() would return right |away. Reading one byte at a time won't resolve this problem, |obviously it will only make it worse. The only reason to |read one byte at a time is for data-terminated read semantics, |specifically readline(), in an unbuffered file. That's what |happens -- at the system call level, where it's expensive -- |when you turn off stdio buffering and then call readline(). | |In the C vs. Python example, read() is os.read(), and file |object read() is fread(); so of course, C read() works |where file object read() doesn't. | |Use select, and os.read (and UNIX) and you can avoid blocking |on a pipe. That's essential if as I am reading it there are supposed |to be two separate pipes from the same process, since if one is |allowed to fill up, that process will block, causing a deadlock if |the reading process blocks on the other pipe. | |Hope I'm not missing anything here. I just follow this group |to answer this question over and over, so after a while it |gets sort of automatic. | | Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
