Hm, I pondered this a little bit. I guess this explains why specialized tools like pexpect exist. I suppose that real-world code reading from a TTY just trusts that select() doesn't lie.
I propose that a good TTY transport for Tulip would be a good thing to have but it would be fine if it was a 3rd party app in PyPI. Yes, it would have to copy some code that exists in almost identical form in asyncio already, but for a case like this I don't mind -- copying that code means that well-meant improvements to the original code won't break for obscure platforms or end cases that the asyncio authors might not have access to or care about. (In general I believe DRY is overrated -- and Yuri can testify on the validity of my instincts about this in at least one specific case. :-) On Thu, Feb 20, 2014 at 8:40 AM, Victor Stinner <victor.stin...@gmail.com>wrote: > Hi, > > When I tested my "tty.py" example with my patch to support TTY in UNIX > write pipe transport, I found an issue with cat. > > With "cat | python3 examples/tty.py", cat fails with "cat: -: Resource > temporarily unavailable". It looks like setting the O_NONBLOCK flag on > a TTY affects two separated processes (cat and python). > > I wrote two programs to try to understand. > > Output of tty_blocking.py: > --- > stdin: FD 0 > stdout: FD 1 > stderr: FD 2 > > stdin and stdout are the same device? True > stdout and stderr are the same device? True > > stdin: blocking > stdout: blocking > stderr: blocking > > set stdout to non-blocking > > stdin: non-blocking > stdout: non-blocking > stderr: non-blocking > --- > > So setting the non-blocking mode of stdout affects also stdin and stderr. > > Output of "python3 tty_stat.py|python3 tty_stat.py": > --- > [10701] stdin: TTY? True, device 11.5 > [10702] stdin: TTY? False, device 8.60938304 > [10701] stdout: TTY? False, device 8.60938304 > [10702] stdout: TTY? True, device 11.5 > --- > > As expected, the stdin of the reader is connected to the stdout of the > writer: it's the pipe 8.60938304. > > But the stdin of the reader and the stdout of the writer are the same > TTY: device 11.5. > > Setting the O_NONBLOCK flag on a TTY affects all processes. asyncio > should not do that, but it means that os.read() or os.write() might > block!? > > Victor > -- --Guido van Rossum (python.org/~guido)
