-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys.stdin.read() doesn't return after first EOF on Windows #49755
Comments
Platform: Windows Vista x64 When I use sys.stdin.readlines(), it correctly ends when I enter ^Z Repro steps:
|
(cannot reproduce under Linux) |
I can reproduce this on coLinux(debian). But coLinux is running on |
With following patch for investigation, (release30-maint) Index: Lib/io.py --- Lib/io.py (revision 70450)
+++ Lib/io.py (working copy)
@@ -57,6 +57,7 @@
import os
import abc
+import sys
import codecs
import _fileio
# Import _thread instead of threading to reduce startup cost
@@ -931,6 +932,7 @@
while True:
# Read until EOF or until read() would block.
chunk = self.raw.read()
+ print("============>", repr(chunk), file=sys.stderr)
if chunk in empty_values:
nodata_val = chunk
break /////////////////////// I got this result. >>> sys.stdin.read()
abc
^Z
============> b'abc\n'
^Z
============> b''
'abc\n' To get empty chunk, we need to hit CTRL-Z twice. |
Perhaps using just one read() is enough? I mean perhaps no loop is |
This is happening on Arch Linux as well: Python 3.0.1 (r301:69556, Feb 22 2009, 02:43:30) I tried python2.6 and it ends with one Ctrl+D |
Looks like python needs eof() or something for file objects, just like Since read() is using the system call, that's the right behavior: read() The 2nd EOF mark without anything in-between will return an empty string. |
This is a duplicate of bpo-1633941 |
I am still able to reproduce the problem with Python 3.2.1RC1 (64 bits) on Windows Seven, but not on Python 3.3 (alpha) compiled myself (using Visual C++ Express 2008). I don't know if something changed in Python 3.3, or it is related to how I compiled Python? I don't think that it is related to issue bpo-12016 because Python 3.2.1RC1 contains the fix for bpo-12016. |
Yes, something changed in Python 3.3. I fixed this issue "by mistake" :-) The fix is the following commit: New changeset 3c7792ec4547 by Victor Stinner in branch 'default': It is a bug in BufferedReader, a bug or an unexpected behaviour. Before this commit (e.g. in Python 3.2.0), BufferedReader.read(-1) calls raw.read() two times for this issue: the first call returns an non empty string (the string until the first ^Z), the second call returns an empty string (the string until the second ^Z). BufferedReader.read(-1) loop ends with raw.read() returns an empty string. You can workaround this issue by calling sys.stdin.buffer.raw.readall() or sys.stdin.buffer.raw.read(-1). I chose to not port my BufferedRead.read(-1) fix (call raw.readall() if available) in Python 3.2 because it changes the behaviour, and I don't want to do that in a minor release. Is anyone in favor of changing the behaviour of BufferedRead.read(-1) in a minor release (next 2.7.3 and 3.2.2)? Or can I close the issue (the bug is already fixed in Python 3.3)? |
I get this on Linux with ^D |
With which Python version? Did you try Python 3.3 (development version)? |
Feel like a total noob: Where do I get the latest source? I can't find any pre-release tarballs for 3.3, and the suggested py3k checkout doesn't work: $ hg clone http://hg.python.org/cpython#py3k py3k |
See the developer's guide: http://docs.python.org/devguide/setup.html#getting-the-source-code hg clone http://hg.python.org/cpython directory_name |
This version is fixed for me: $ ./python
Python 3.3.0a0 (default:7520f1bf0a81, Jul 18 2011, 17:12:12)
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2 |
@pitrou: Antoine, do you think that the following commit should be backported from 3.3 to 3.2? New changeset 3c7792ec4547 by Victor Stinner in branch 'default': It changes BufferedReader.read() behaviour a *little* bit. Only a little because FileIO.read(-1) calls FileIO.readall() internally for example. |
No, I don't think so. |
The issue is already fixed in 3.3, so you agree to not fix it in Python 3.2? |
Since this was apparenly only a bug in 3.2, can we close it as being out of date? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: