[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: OK, I'm closing this as won't fix. If someone disagrees please explain. -- resolution: -> wont fix status: open -> closed ___ Python tracker _

[issue5380] pty.read raises IOError when slave pty device is closed

Xavier de Gaye added the comment: The line discipline [1] of a terminal driver and a pty is controlled by terminal attributes set with tcsetattr() [2][3]. IMHO (as a developer running ptys over asyncio), using a pty implies writing code at the low level such as configuring the line discipline,

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Márcio : -- nosy: -marcio ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/ma

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: So maybe we should just close this as won't fix. Whoever wants to use the master end of a pty had better be prepared for that IOError. On Thursday, October 8, 2015, Martin Panter wrote: > > Martin Panter added the comment: > > My biggest worry about the patc

[issue5380] pty.read raises IOError when slave pty device is closed

Martin Panter added the comment: My biggest worry about the patch is that it looks like it will mask other EIO errors from normal terminals (e.g. perhaps reading from a slave or a real serial port can also produce an EIO error that does not mean EOF). Another option may be to add a specialized

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: Honestly, Antoine's patch looks reasonable to me (except that the names of the test modules perpetuate the confusion that pipes and ptys are similar). Can someone just port that to 3.6? (The change in semantics is big enough that I don't think we should shov

[issue5380] pty.read raises IOError when slave pty device is closed

Xavier de Gaye added the comment: TLPI (The Linux Programming Interface book) says about the pty implementation on linux, at section 5 of chapter 64: If we close all file descriptors referring to the pseudoterminal slave, then: a) A read() from the master device fails with the error EI

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: Indeed, ptys and pipes behave very differently (that's why we have both -- they serve different purposes). More relevant question: we should find a way to decide whether to either apply Antoine's patch or close this issue. Finally, maybe array.fromfile() ca

[issue5380] pty.read raises IOError when slave pty device is closed

Martin Panter added the comment: I don’t think it is right to assume pseudo-terminals behave exactly like pipes. I suspect the behaviour when the slave is closed is undefined, or at best platform-specific, and there is no bug to fix in Python. Also, it looks like array.fromfile() assumes any s

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Márcio Faustino : -- nosy: +marciof ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue5380] pty.read raises IOError when slave pty device is closed

Zac Medico added the comment: This issue no longer appears to be a problem for my purposes, since it seems that array.fromfile() does not lose any data as long as the input file is opened in unbuffered mode (I use fdopen with 0 for the bufsize argument). -- __

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Worse, the test timed out (probably froze) on the Solaris buildbot: http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/649/steps/test/logs/stdio -- ___ Python tracker

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file16861/io-openpty.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Regardless of the decision, a new patch. -- Added file: http://bugs.python.org/file16863/io-openpty.patch ___ Python tracker ___ ___

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: After triggering the buildbots, it seems that reading from the master fd after the slave fd has been closed is rather OS-dependent. The FreeBSDs return an empty string. I wonder whether this use case (reading from the master after the slave is closed) should rea

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Antoine Pitrou : Added file: http://bugs.python.org/file16861/io-openpty.patch ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file16859/io-openpty.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: It turns out isatty() returns True for fds created by openpty(), which helps quite a bit: we can silence EIO for ttys while keeping it for non-ttys, where a low-level I/O (hardware) error should be raised properly. Here is a patch for trunk. -- keywor

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Albert Hopkins : -- nosy: +marduk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Uh, a file descriptor returned by openpty() doesn't satisfy S_ISFIFO(). It's just reported as a character device by fstat (st_mode is 0o20666). Perhaps the best thing is to just let the error propagate, since after all the user tries to read more bytes than are

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Will try to work out a patch before the RC. -- assignee: -> pitrou components: +IO priority: -> normal stage: -> needs patch versions: +Python 3.1 -Python 3.0 ___ Python tracker

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: > Well, as I suggested, in FileIO.read(): when receiving errno=5 on a > read() call and if S_IFIFO() returns true, clear errno and return an > empty string. > The question is whether a genuine EIO error ("low level IO error") can > occur on a FIFO. Intuitively

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Well, as I suggested, in FileIO.read(): when receiving errno=5 on a read() call and if S_IFIFO() returns true, clear errno and return an empty string. The question is whether a genuine EIO error ("low level IO error") can occur on a FIFO. Intuitively, I'd say "n

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: That may be how it works, but how do you expect to deal with it? ___ Python tracker ___ ___ Python-bugs-lis

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Guido: I don't know if it can be considered as a "bug" rather than a misguided "feature". However, at least 3 of us (the OP, Hirokazu and I) reproduce it (as for me, it's on a quite recent x86-64 Mandriva Linux setup), so I imagine it's not totally exotic behavi

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Jean-Paul Calderone : -- nosy: +exarkun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue5380] pty.read raises IOError when slave pty device is closed

Guido van Rossum added the comment: IIUC the problem is that a read() syscall on the pty after the other end has been closed raises an error instead of reading 0 bytes? Isn't that a bug in the pty implementation? For lots of devices (e.g. sockets, pipes) a short non-empty read just means that y

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Antoine Pitrou : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue5380] pty.read raises IOError when slave pty device is closed

Antoine Pitrou added the comment: Interesting. The reason the io module calls read() more than once is that BufferedReader is a generic wrapper which can be used on different kinds of file-like objects, including sockets. I'm not sure how to satisfy that use-case without compromising normal err

[issue5380] pty.read raises IOError when slave pty device is closed

Changes by Hirokazu Yamamoto : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue5380] pty.read raises IOError when slave pty device is closed

Hirokazu Yamamoto added the comment: This OSError(5) happens when we tries to read from pty after data runs out. So simple_test_2.py fails with same error even if we don't use io module. Modules/posixmodule.c (posix_read) simply calls read(2) once, but io module while avail < n: ch

[issue5380] pty.read raises IOError when slave pty device is closed

Hirokazu Yamamoto added the comment: I think this is not array modules' bug. Attached test program outputs different results on trunk/py3k. debian:~/python-dev/trunk# ./python /mnt/windows/simple_test.py os.pipe: success pty.openpty: success debian:~/python-dev/py3k# ./python /mnt/windows/simp