Ah, clever. It needs a little more research--is it always the case that a
tty FD works this way? But tentatively worth getting into RC2.
On Feb 19, 2014 8:32 AM, "Victor Stinner" <victor.stin...@gmail.com> wrote:
> Hi,
>
> 2014-02-19 16:46 GMT+01:00 Jonathan Slenders <jonathan.slend...@gmail.com
> >:
> > Late reply, but two-way pipe transport or something that feels like a
> better
> > API would be really nice.
>
> I'm not sure that I understand correctly. stdin are stdout have a
> different file descriptor: 0 and 1. But in case of PTY, it looks like
> 0 and 1 are the same file: os.path.samestat(os.fstat(0), os.fstat(1))
> is True.
>
> Do you mean that we need a duplex pipe transport when stdin and stdout
> are the same PTY?
>
> Does it make sense to wait for read event on the PTY in the write pipe
> transport? It looks like writing data into the PTY raises a read
> event, and os.read() on the file descriptor returns the written data.
>
> What do you think of the following patch? It fixes the initial example.
>
> diff -r f7b20eaefa3c asyncio/unix_events.py
> --- a/asyncio/unix_events.py Tue Feb 18 10:02:52 2014 +0100
> +++ b/asyncio/unix_events.py Wed Feb 19 17:29:20 2014 +0100
> @@ -266,7 +270,7 @@ class _UnixWritePipeTransport(selector_e
> # On AIX, the reader trick only works for sockets.
> # On other platforms it works for pipes and sockets.
> # (Exception: OS X 10.4? Issue #19294.)
> - if is_socket or not sys.platform.startswith("aix"):
> + if is_socket or not sys.platform.startswith("aix") and not
> os.isatty(self._fileno):
> self._loop.add_reader(self._fileno, self._read_ready)
>
> self._loop.call_soon(self._protocol.connection_made, self)
>
> Victor
>
