IOError：[Errno 32]管道损坏：Python

我有一个非常简单的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

我没有重现这个问题，但是也许这种方法可以解决这个问题：（逐行写入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

问题是由于SIGPIPE处理。您可以使用以下代码解决此问题：

from signal import signal, SIGPIPE, SIG_DFL
signal(SIGPIPE,SIG_DFL) 

有关此解决方案的背景信息，请参见此处。最好在这里回答。

要将Alex L.的有用答案， akhan的有用答案和Blckknght的有用答案以及一些其他信息结合在一起：

• 标准Unix信号SIGPIPE被发送到进程写入到一个管道时，有没有进程读取从管道（了）。

  • 这不一定是错误条件；一些Unix工具，如head 设计停止从管道过早地阅读，一旦他们已经收到了足够的数据。

• 默认情况下（即，如果写入过程未显式陷入陷阱 SIGPIPE），写入过程将简单地终止，并且其退出代码设置为141，其计算公式为128（通常以信号表示信号终止）+ 13（SIGPIPE特定信号编号） 。

• 但是，根据设计，Python本身会捕获SIGPIPE它IOError并将其转换为具有errnovalue的Python实例errno.EPIPE，以便Python脚本可以捕获它（如果可以选择的话）-有关方法，请参见Alex L.的答案。

• 如果一个Python脚本并没有抓住它，Python的输出错误信息IOError: [Errno 32] Broken pipe和终止，退出代码脚本1-这是症状的OP锯。

• 在许多情况下，这更具破坏性，而不是有所帮助，因此，需要恢复为默认行为：

  • 如akhan的回答所述，使用signal模块可以做到这一点；将要处理的信号作为第一个参数，将处理程序作为第二个参数；特殊处理程序值表示系统的默认行为：signal.signal()SIG_DFL

    from signal import signal, SIGPIPE, SIG_DFL
    signal(SIGPIPE, SIG_DFL) 
    

当您尝试写入另一端已关闭的管道时，会发生“管道破裂”错误。由于您显示的代码不直接涉及任何管道，因此我怀疑您在Python之外进行了一些操作，以将Python解释器的标准输出重定向到其他地方。如果您正在运行以下脚本，则可能会发生这种情况：

python foo.py | someothercommand

您遇到的问题someothercommand是退出时没有阅读其标准输入上的所有可用信息。这会导致您的写入（通过print）在某些时候失败。

我能够在Linux系统上使用以下命令来重现该错误：

python -c 'for i in range(1000): print i' | less

如果关闭less翻页器而不滚动其所有输入（1000行），Python会以IOError您报告的状态退出。

我觉得有必要指出

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

我知道这不是执行此操作的“正确”方法，但是如果您只是对摆脱错误消息感兴趣，可以尝试以下解决方法：

python your_python_code.py 2> /dev/null | other_command

if e.errno == errno.EPIPE:此处的最高答案（）不适用于我。我有：

AttributeError: 'BrokenPipeError' object has no attribute 'EPIPE'

但是，如果您只关心忽略特定写入操作中损坏的管道，则此方法应该起作用。我认为这比捕获SIGPIPE更安全：

try:
    # writing, flushing, whatever goes here
except BrokenPipeError:
    exit( 0 )

显然，您必须决定如果碰到破损的管道，您的代码是否真的完成，但是对于大多数目的，我认为通常是正确的。（不要忘记关闭文件句柄等）

如果脚本输出的读取端过早死亡，也会发生这种情况

即open.py | otherCommand

如果otherCommand退出并且open.py尝试写入stdout

我有一个糟糕的gawk脚本，这对我来说很可爱。

关闭应以与打开相反的顺序进行。