Broken pipe一般都是什么原因导致的错误

Question

如题所述

Answer 1

很多种原因：
1、网络通讯中，连接意外中断，比如被人拔了网线；
2、进程间通讯中管道断裂，譬如管道某一端进程僵死；
3、文件描述符终端，多见于*Nix，当退出登录时，虚拟终端断开，导致文件描述符1和2消失；
扩展资料：
首先我说一下为什么要写这么一篇文章。有两个原因，一个原因是下面要说的问题本身确实有一些代表性，虽然不是什么高深的问题，但是了解一下总是好的，对于学习和使用Linux系统会很有帮助。第二个原因是我被知乎上越来越多的无脑的问题问得烦透，借这个问题本身引申一下我的一些看法。
我不止一次在不同场合下表达过对于一些问问题的看法，比如：
醉卧沙场：关于知乎作业和个人任务的问题如何对待？
Windows系统崩溃蓝屏，请问怎么看出下面的问题是系统问题还是硬件的问题？
希望问问题的人能理解回答和解决问题的人的思考角度以及解题的过程。一个问题从现象到本质的分析不是你说“大夫，我发烧了，不好受”，然后大夫直接给你开点退烧药这么简单。一个问题从现象到本质，从一般人眼中的“显而易见”到专业人员的“可以论述和解决”是完全不同的两个世界。
一个问题的开始
这两天以前的一个bash脚本突然工作异常，从表面上看就是一个不会失败的程序突然间开始出现失败。经过查看错误输出，可以发现是一个本不应该被执行的语句被执行了，进而说明一个本不应该成立的判断语句竟然突然间变的“成立”了。因为经过了很多函数的嵌套，我为了说明方便，将那条判断语句简化如下（注意是极度简化的语句）：
if ! mkfs.xfs -f /dev/loop0 | grep -q crc=1; then
do_something
fi
本来这条do_something的语句是不被预期执行的，但是它却被执行了，说明 if 那条判断语句成立了。从字面上理解，应该是grep没有从mkfs.xfs的输出中找到crc=1这个关键字，所以条件成立，执行了do_something。但是我单独实际查看mkfs.xfs的输出时，却是能得到crc=1的：
# mkfs.xfs -f /dev/loop0 | grep crc=1
= crc=1 finobt=1， sparse=1， rmapbt=0
可以看到grep是找得到crc=1的。

于是我开始怀疑是不是mkfs.xfs的bug导致mkfs.xfs操作成功后仍然返回错误。但是单独执行mkfs.xfs并无异样：
# mkfs.xfs -f /dev/loop0
meta-data=/dev/loop0 isize=512 agcount=4， agsize=983040 blks
= sectsz=512 attr=2， projid32bit=1
= crc=1 finobt=1， sparse=1， rmapbt=0
= reflink=1
data = bsize=4096 blocks=3932160， imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0， ftype=1
log =internal log bsize=4096 blocks=2560， version=2
= sectsz=512 sunit=0 blks， lazy-count=1
realtime =none extsz=4096 blocks=0， rtextents=0
Discarding blocks...Done.
# echo $?
0
难道是grep出现了bug，-q会导致找到匹配项仍然返回错误？但是测试后说明grep也无异样：
# echo "crc=1 finobt=1， sparse=1， rmapbt=0" | grep -q crc=1
# echo ${PIPESTATUS[1]}
0
嗯

Answer 2

很多种原因：
1、网络通讯中，连接意外中断，比如被人拔了网线；
2、进程间通讯中管道断裂，譬如管道某一端进程僵死；
3、文件描述符终端，多见于*Nix，当退出登录时，虚拟终端断开，导致文件描述符1和2消失；本回答被提问者和网友采纳

Answer 3