Python 为什么sys.stdin.read（）返回''；永久不寻求输入？

在玩

sys.stdin.read（）

（终端，Mac OS Sierra）时，发现它变得不可用时有奇怪的行为。发生了什么事

#Python 2.7.13
导入系统
sys.stdin.read（）
#等待输入
#用户按ctrl-d键（无任何输入）
#返回“”
sys.stdin.read（）
#不等待输入
#立即返回“”
sys.stdin.read（）
# ''
sys.stdin.read（）
# ''

注意：Mac上的ctrl+d=EOF，Windows上的ctrl+z

更新：我注意到任何长度为5的字符串都有相同的行为，只有一行是新行…短/长字符串或多/少新行的行为正常

#Python 2.7.13
导入系统
sys.stdin.read（）
12345
#按ctrl-d两次（使单行字符串工作的唯一方法？）
'12345'
#工作正常
sys.stdin.read（）
1234
#用户按return键，然后按ctrl-d键
“1234\n”
#工作正常
sys.stdin.read（）
12345
#返回，返回，ctrl-d
“12345\n\n”
#工作正常
sys.stdin.read（）
12345
#返回，ctrl-d
“12345\n”
#没用…见下一个电话
sys.stdin.read（）
#不等待输入
#立即返回“”
''

---

我想了解在程序中使用这种行为的原因。我一定会在代码中检查它，但仍然希望了解如何避免这两个不起作用的实例。

我不确定，这就是为什么我不发布答案的原因，但我认为问题就在这里：EOF是文件的结尾，而不是行的结尾。EOF表示将不再有任何输入。虽然这不是一个严格的技术要求（毕竟，它只是一个字符），但Terminal（或者，就这个问题而言，Python）可能会对它进行特殊处理（我猜是Terminal）。有趣的是，我只能在Python2.7上得到这一点。在Python3.6中，每次调用

read（）

都会等待输入，并在每次按下时返回

^D

。（在OS X El Capitan上，使用iTerm2或Terminal.app.Ok，再看一看，这可能与此SO post（）和此Python bug（）有关。读取方法的底层实现在Python2和3之间的缓冲方式不同。如果我使用Python2，并将

sys.stdin.read（）

更改为

sys.stdin.readline（））

，则Python2和pytho3中的行为相同。非常确定

'

是表示“EOF”的返回值对于

stdin

。这就是为什么您将其设置为子流程管道之类的EOF信号。Python 2实现只是拒绝返回超过第一个EOF的任何内容，这实际上是非常合理的，即使并不总是正确的。