[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

[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

[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

[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

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

Changes by Márcio : -- nosy: -marcio ___ Python tracker ___ ___ Python-bugs-list

[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

[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

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

Changes by Márcio Faustino marciombfaust...@gmail.com: -- nosy: +marciof ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___ ___

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

Zac Medico zmed...@gentoo.org 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 pit...@free.fr 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.

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

Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file16859/io-openpty.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___

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

Changes by Antoine Pitrou pit...@free.fr: Added file: http://bugs.python.org/file16861/io-openpty.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___

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

Antoine Pitrou pit...@free.fr 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

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

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

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

Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file16861/io-openpty.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___

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

Antoine Pitrou pit...@free.fr 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

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

Changes by Albert Hopkins mar...@python.net: -- nosy: +marduk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___ ___ Python-bugs-list mailing

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

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___

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

Antoine Pitrou pit...@free.fr 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

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

Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org

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

Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp 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#

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

Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp 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

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

Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___ ___

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

Antoine Pitrou pit...@free.fr 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

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

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___ ___ Python-bugs-list mailing

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

Guido van Rossum gu...@python.org 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

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

Changes by Jean-Paul Calderone exar...@divmod.com: -- nosy: +exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___ ___ Python-bugs-list

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

Antoine Pitrou pit...@free.fr 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

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

Guido van Rossum gu...@python.org added the comment: That may be how it works, but how do you expect to deal with it? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5380 ___

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

Antoine Pitrou pit...@free.fr 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.

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

Guido van Rossum gu...@python.org 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.