我有一个非常简单的Python 3脚本：
f1 = open('a.txt', 'r')
print(f1.readlines())
f2 = open('b.txt', 'r')
print(f2.readlines())
f3 = open('c.txt', 'r')
print(f3.readlines())
f4 = open('d.txt', 'r')
print(f4.readlines())
f1.close()
f2.close()
f3.close()
f4.close()
但它总是说：
IOError: [Errno 32] Broken pipe
我在互联网上看到了很多复杂的方法来解决这个问题，但我直接复制了这段代码，所以我认为代码有问题，而不是 Python 的 SIGPIPE 有问题。
我正在重定向输出，所以如果上面的脚本名为“open.py”，那么我运行的命令将是：
open.py | othercommand
当一个进程从一个管道写入数据时，如果没有其他进程在读取该管道（或已经停止读取），则会向该进程发送标准Unix信号SIGPIPE。
head）在接收到足够的数据后就有意地提前停止从管道中读取。head命令进行管道传输（参见以下示例）：
python -c 'for x in range(10000): print(x)' | head -n 1默认情况下，即如果写入进程没有显式地捕获SIGPIPE信号，则该进程将被简单地终止，并且其退出代码将被设置为141，计算公式为128（一般情况下表示通过信号终止） + 13（代表SIGPIPE信号）。
然而，Python 本身会捕获SIGPIPE信号，并将它转换为一个Python BrokenPipeError（Python 3）/IOError（Python 2）实例，其errno值为errno.EPIPE。
如果Python脚本没有捕获此异常，Python将输出错误消息BrokenPipeError: [Errno 32] Broken pipe（对于Python 3而言，可能出现两次此错误信息，并插入Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>）/IOError: [Errno 32] Broken pipe（对于Python 2而言），并且以退出代码1终止该脚本[2] - 这就是Johannes（原问题作者）所看到的症状。
Windows注意事项（SIGPIPE是仅适用于Unix的信号）
如果您的脚本还需要直接在Windows上运行，您可能需要有条件地绕过引用SIGPIPE的代码，如此答案所示。
如果您的脚本在Windows上的Unix子系统中运行，则SIGPIPE信号可能会与Unix上的不同方式出现 - 请参见此答案。
解决此问题有两种方法：
通常，不建议 消除 此异常，因为它可能表示严重错误条件，取决于您的脚本目的，例如网络套接字接收端意外关闭。
head实用程序很好地配合使用，您可以使用signal.signal()来安装平台的默认信号处理程序（其行为如上所述），如akhan的回答所示（适用于Python 3和2）：# ONLY SUITABLE FOR COMMAND-LINE UTILITIES
# Install the default signal handler.
from signal import signal, SIGPIPE, SIG_DFL
signal(SIGPIPE, SIG_DFL)
# Start printing many lines.
# If this gets interrupted with SIGPIPE,
# the script aborts quietly, and the process exit code is set to
# 141 (128 + SIGPIPE)
for x in range(10000): print(x)
import sys, os, errno
try:
# Start printing many lines.
for x in range(10000): print(x)
# IMPORTANT: Flush stdout here, to ensure that the
# SIGPIPE-triggered exception can be caught.
sys.stdout.flush()
except IOError as e:
# Note: Python 3 has the more specific BrokenPipeError,
# but this way the code works in Python 2 too.
if e.errno != errno.EPIPE: raise e # Unrelated error, re-throw.
# Python flushes standard streams on exit; redirect remaining output
# to devnull to avoid another BrokenPipeError at shutdown
devnull = os.open(os.devnull, os.O_WRONLY)
os.dup2(devnull, sys.stdout.fileno())
# ... perform other handling.
# Note: You can't write to stdout here.
# (print() and sys.stdout.write won't work)
# However, sys.stderr.write() can be used.
sys.stderr.write("SIGPIPE received, terminating.\n")
# Finally, exit with an exit code of choice.
sys.exit(141)
[1] 请注意，在bash中，默认情况下只会看到head的退出码 - 即0 - 在之后反映在$?中。使用echo ${PIPESTATUS[0]}来查看Python的退出码。
[2] 奇怪的是，在macOS 10.15.7（Catalina）上，使用Python 3.9.2（但不是2.x），我看到退出码为120，但文档说是1，这也是我在Linux上看到的。
我没有复现这个问题，但也许这种方法可以解决它：（逐行写入stdout而不使用print）
import sys
with open('a.txt', 'r') as f1:
for line in f1:
sys.stdout.write(line)
你能捕获断开的管道吗？这个命令会逐行将文件写入到stdout，直到管道被关闭。
import sys, errno
try:
with open('a.txt', 'r') as f1:
for line in f1:
sys.stdout.write(line)
except IOError as e:
if e.errno == errno.EPIPE:
# Handle error
你还需要确保othercommand在管道数据太多之前就从中读取 - https://unix.stackexchange.com/questions/11946/how-big-is-the-pipe-buffer
print调用有关，而不是读取文件） 。 - Blckknghtsys.stdout.write(line + '\n')。 - undefined"Broken Pipe"错误会在你尝试向一个已经被关闭了的管道写入数据时发生。由于你展示的代码并没有直接涉及任何管道，我猜测你正在Python之外进行一些操作，将Python解释器的标准输出重定向到其他地方。如果你像这样运行脚本，就可能会遇到这种问题：
python foo.py | someothercommand
你遇到的问题是 someothercommand 没有读取完其标准输入而退出。这会导致你通过 print 写入的内容在某个时刻失败。
我在 Linux 系统上使用以下命令重现了这个错误：
python -c 'for i in range(1000): print i' | less
如果我没有滚动查看所有输入（1000行）就关闭less分页器，则Python会出现与您报告的相同的IOError错误。
SIGPIPE信号并不一定表示出现了错误情况；一些Unix实用程序（特别是head）在正常操作期间有意为之，在它们读取完自己所需的数据后提前关闭管道。 - mklement0我感到有责任指出，使用的方法是
signal(SIGPIPE, SIG_DFL)
正如David Bennet在评论中所建议的那样，确实很危险，并且在我的情况下，当与multiprocessing.Manager组合使用时会导致特定于平台的有趣问题（因为标准库依赖于在多个地方引发BrokenPipeError）。为了简短而痛苦地讲述这个故事，以下是我解决它的方法：
首先，您需要捕获IOError（Python 2）或BrokenPipeError（Python 3）。根据您的程序，您可以尝试在此时尽早退出或仅忽略异常：
from errno import EPIPE
try:
broken_pipe_exception = BrokenPipeError
except NameError: # Python 2
broken_pipe_exception = IOError
try:
YOUR CODE GOES HERE
except broken_pipe_exception as exc:
if broken_pipe_exception == IOError:
if exc.errno != EPIPE:
raise
然而，这还不够。Python 3可能仍会打印出像这样的消息：
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe
很遗憾，消除这个消息并不容易，但我终于在http://bugs.python.org/issue11380找到了Robert Collins建议的解决方法，我把它变成一个装饰器，你可以用它来包装你的主函数（是的，那是一些疯狂缩进）:
from functools import wraps
from sys import exit, stderr, stdout
from traceback import print_exc
def suppress_broken_pipe_msg(f):
@wraps(f)
def wrapper(*args, **kwargs):
try:
return f(*args, **kwargs)
except SystemExit:
raise
except:
print_exc()
exit(1)
finally:
try:
stdout.flush()
finally:
try:
stdout.close()
finally:
try:
stderr.flush()
finally:
stderr.close()
return wrapper
@suppress_broken_pipe_msg
def main():
YOUR CODE GOES HERE
suppress_broken_pipe_msg 位来静默掉 <_io.TextIOWrapper 消息中的 Exception ignored in: 提示，并且第一个 except broken_pipe_exception 代码块可以在 Python 2/3 兼容的情况下处理断开的管道异常。 - Nickolay我知道这不是正式的做法，但是如果你只是想把错误消息去掉，可以尝试这个解决方法：
python your_python_code.py 2> /dev/null | other_command
python your_python_code.py | tee /dev/null | other_command也可以工作。但我不明白为什么它能处理stderr。 - Ilia w495 Nikitin/dev/null 吗？ - ssanchif e.errno == errno.EPIPE:）对我并没有起作用。我收到了以下错误信息：AttributeError: 'BrokenPipeError' object has no attribute 'EPIPE'
然而，如果你只关心特定写入时忽略损坏的管道，这应该会生效。我认为这比捕获SIGPIPE更安全:
try:
# writing, flushing, whatever goes here
except BrokenPipeError:
exit( 0 )
当你遇到“broken pipe”错误时，显然你需要决定你的代码是否真正完成，但大多数情况下我认为通常是正确的。(不要忘记关闭文件句柄等操作。)
PYTHONUNBUFFERED=1可能会有帮助，它可以强制stdout和stderr流无缓冲。参见：https://docs.python.org/3/using/cmdline.html#cmdoption-u
因此，您的命令是：open.py | othercommand
变成：
PYTHONUNBUFFERED=1 open.py | othercommand
例子：
$ python3 -m http.server | tee -a access.log
^CException ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe
$ PYTHONUNBUFFERED=1 python3 -m http.server | tee -a access.log
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
^C
$
head，在正常操作期间会 设计 尽早关闭管道，一旦它们读取了所需的数据。大多数 CLI 简单地遵循系统的默认行为：静默终止读取进程并报告退出代码 141（在 shell 中不容易看出来，因为管道的 最后 命令决定了整体退出代码）。不幸的是，Python 的默认行为是发出嘈杂的错误信息。 - mklement0关闭应该按照打开的相反顺序进行。
print(f1.readlines())- JOHANNES_NYÅTTa.txt读取和写入到stdout。也许尝试将它们分成单独的行，以便您可以看到哪个操作触发了异常。如果stdout是一个管道，并且读端已关闭，则可能会导致EPIPE错误。 - James Henstridgeprint调用是罪魁祸首。@JOHANNES_NYÅTT，你能澄清一下你是如何启动你的Python脚本的吗？你是否将标准输出重定向到某个地方？ - Blckknght