什么是“管道”？如何“断开”？

我从Xcode收到“断管”错误的次数太多了。我现在很好奇确切地知道什么是管道。

“管道”的概念是什么？如何“破裂”？

管道只是一种进程间通信（IPC）机制，用于将一个过程的标准输出连接到另一个过程的标准输入。

例如，当您要在文件中搜索单词“ pax”时：

cat filename | grep pax

是的，我知道您可以grep直接打开文件，但这不能解释文件的工作原理，对吗？

这会将cat命令的标准输出连接到命令的标准输入grep。cat将文件的内容发送到其标准输出，并grep从其标准输入读取文件（在这种情况下）。通过这样将流程连接在一起，您可以创建自己的工具，该工具由任意数量的管段组成。像：

show_users | grep pax | awk -F: '{print $4}' | tr '[a-z]' '[A-Z]' | cut -c1-20

甲破管是其中（通常）的数据的接收器已经关闭了连接，而发送者仍试图通过发送东西。

例如，如果您通过寻呼程序发送大文件（一次查看一页）：

cat myfile | pager

然后执行a CTRL-BREAK，这可能导致pager进程cat在使用完输入管之前将其关闭。这是弄坏管道的一种可能性。

从粗略的Google搜索来看，这个特殊问题似乎与临时部署有关，并且给出的解决方案通常包括退出大多数软件并重新引导大多数设备。

这可能已经严重到足以向苹果报告该问题。抱怨的开发者越多，将有更多的机会修复它。

该|角色通常称为管道。在各种UNIX shell（我知道）中，可以用来将一个命令的输出传递给另一个命令的输入。

cat myfile.txt | head

该head命令仅显示其输入的前几行。此时，它关闭其输入。这对生成输入的命令造成了问题。它写在哪里？每当我们遇到这种情况，或者在读者通过之前写过程结束的情况时，它都被称为“断管”。

为了防止该cat命令永远徘徊，UNIX标准定义了一个特殊信号（SIGPIPE，信号13），它将发送给该信号cat。此信号的默认操作是cat终止进程，从而使结束顺利进行。

您正在使用的应用程序似乎已为所有信号（包括SIGPIPE）安装了信号处理程序，该信号处理程序会创建您看到的小弹出消息。

该错误似乎经常出现。 /programming/490366/ad-hoc-deployment-issue-putpkt-write-failed-broken-pipe 这是“ ... Xcode与您的电话通话能力的内部错误。它不是表示您做错了什么，这是开发系统中的错误”

管道是Unix系统上的IPC机制。管道具有两个端部：读取端和写入端。可以从读取端读取写入到写入端的数据，并按写入顺序将其输出。

在Unix命令行世界中，管道是将程序挂钩在一起以完成工作的非常常见的方式。例如，sed 's/foo/bar/g' fred.txt | grep -e 'bar.*baz'将在文件中读取的fred.txt所有实例替换为字符串foo，bar然后在结果中搜索包含bar以下字符的行，然后搜索baz。

当然，这似乎并不是非常有用。但是我敢肯定，如果您考虑过这一点，便可以了解如何将其用于各种有趣的用途，尤其是当您拥有类似awk或perl可供使用的程序时。

从很早开始，管道系统就已成为Unix的一部分。而且，如果管道中的进程退出，则通常希望管道中的所有程序退出。这意味着，默认情况下，在读取端的进程消失后，写入管道的进程将获得SIGPIPE信号。并且，如果它阻止了该信号，write它将仍然失败，并出现一种特殊的错误，表明管道已“损坏”。

默认处理将SIGPIPE杀死接收它的进程。如果它不是管道的“头”，那么整个SIGPIPE过程就会在链中向上传播。

Xcode抱怨的是，它启动了一个子程序来处理通向它的管道，并且该子程序意外死亡，导致管道破裂。

“断”管道是指一端已被close()插入而另一端正在被读取或写入的管道。例如，在以下shell命令中：

cat foo | less

该cat过程将保留管道的写入端，而less过程将读取该端。如果读取器进程关闭了管道，则管道破裂（因此无用）；编写器进程将收到来自操作系统的“管道中断”错误。