如何解决管道破裂的错误？

在获得SSD驱动器后，在全新安装Ubuntu 12.10之后，我最近重新安装了RVM（按照http://rvm.io上的说明）。

现在，当我键入： type rvm | head -1

我收到以下错误：

rvm is a function
-bash: type: write error: Broken pipe

但是，如果我立即重复该命令，那么我只会收到：

rvm is a function

看来一切都还好吗？发生了什么？我该如何解决？它并不总是发生。它似乎是零星的。我已经尝试找到某种模式，但是还没有。

在这种情况下很少见到“破损的管道”，但这很正常。

当您运行时type rvm | head -1，bash type rvm在一个进程head -1中执行，在另一个进程中执行。¹的标准输出type连接到管道的“写入”端，的标准输入head连接到“读取”端。这两个过程同时运行。

该head -1过程从stdin读取数据（通常以8 kB为块），打印出一行（根据-1选项），然后退出，从而导致管道的“读取”端关闭。由于该rvm功能相当长（由bash解析和重建后约为11 kB），因此这意味着head退出时type仍需要写入几kB的数据。

此时，由于type试图写入另一端已关闭的管道（损坏的管道），因此它校准的write（）函数将返回EPIPE错误，翻译为“损坏的管道”。除了此错误外，内核还将SIGPIPE信号发送给type，默认情况下，该信号立即终止进程。

（该信号在交互式Shell中非常有用，因为大多数用户不希望第一个进程继续运行并试图写到任何地方。同时，非交互式服务会忽略SIGPIPE –对于长时间运行的守护程序而言，这样做不利。死于如此简单的错误-因此他们发现错误代码非常有用。）

但是，信号传递不是立即100％进行的，在某些情况下，write（）返回EPIPE，并且该过程在接收到信号之前会继续运行一会儿。在这种情况下，type在被SIGPIPE杀死之前，有足够的时间来注意到写入失败，翻译错误代码甚至将错误消息打印到stderr。（错误消息显示为“ -bash：类型：”，因为它type是bash本身的内置命令。）

这在多CPU系统上似乎更常见，因为type进程和内核的信号传递代码实际上可以同时在不同的内核上运行。

可以通过修补type内置消息（在bash的源代码中）以在收到来自write（）函数的EPIPE时立即退出的消息来删除此消息。

但是，没有什么可担心的，它与您的rvm安装没有任何关系。

您可以通过在管道中插入来修复损坏的管道，而以另一个过程为代价tail -n +1，如下所示：

输入rvm | 尾-n +1 | 头-1

该+1通知tail打印输入和遵循事物的第一道防线。输出将与tail -n +1不存在的输出完全相同，但是该程序足够智能，可以检查标准输出并干净地关闭管道。不再有破损的管道。

该write error: Broken pipe消息涉及一个写入过程，该过程试图写入一个管道，而该管道的读取端上没有任何读取器，并且在特殊情况下，SIGPIPE信号被设置为被当前进程或父进程忽略。如果设置SIGPIPE为忽略的是父进程，则子进程不可能在非交互shell中再次撤消该操作。

不过，可能杀死type rvm时，head -1通过使用明确的子shell终止。这样，我们可以将background type rvm，发送typepid到head -1subshel​​l，然后在EXIT该处实现陷阱以type rvm明确杀死它。

trap "" PIPE        # parent process sets SIGPIPE to be ignored
bash                # start child process
export LANG=C
# create a fake rvm function
eval "
rvm() {
$(printf 'echo line of rvm code %s\n' {1..10000})
}
"

# rvm is a function
# bash: type: write error: Broken pipe
type rvm | head -1

# kill type rvm when head -1 terminates
# sleep 0: do nothing but with external command
( (sleep 0; type rvm) & echo ${!} ; wait ${!} ) | 
    (trap 'trap - EXIT; kill "$typepid"; exit' EXIT; typepid="$(head -1)"; head -1)