On Wed, Feb 19, 2014 at 11:08 AM, Jonathan Slenders < [email protected]> wrote:
> > > Le mercredi 19 février 2014 17:32:25 UTC+1, Victor Stinner a écrit : > >> 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. >> > > This is because the file descriptor is copied, this is how forkpty works. > To clarify, this is a fundamental property of pseudo ttys. I assume it's similar to sockets: a socket always represents a bidirectional channel, and if you use dup() on a socket, all FDs produced that way will become ready for reading or writing at the same time. (I wouldn't be surprised if real ttys work this way too, but I haven't seen one in over a decade. :-) In any case, the consequence is that even though stdin and stdout (and stderr) use different FDs, they refer to the same object in the kernel, and that object doesn't know which FD you were using to refer to it. So if there's data to be read, this information is available equally through all FDs. > Maybe you can take a look at this line of pexpect: > https://github.com/noahspurrier/pexpect/blob/master/pexpect.py#L630 > > It looks like writing data into the PTY raises a read >> event, and os.read() on the file descriptor returns the written data. >> > > This is only the case when the pty is in canonical mode. (The pty > implements some line editing/buffering functionality itself.) > Hm, I would presume that what you're really observing here is the behavior of whatever process controls the other end (the master). That would be your terminal emulator program. > Maybe you want to set the pty in raw mode first. Everything seems more > logical then: > http://docs.python.org/2/library/tty.html#tty.setraw > This documentation isn't very helpful. It would be more useful to look up the theory and operation of pseudo ttys in some UNIX internals book. > To the questions considering asyncio itself, I don't have a real answer. > Having thought more about it, I am fine with Victor's fix. -- --Guido van Rossum (python.org/~guido)
