Linux中`yes|head`命令的运行机制及SIGPIPE信号触发逻辑是怎样的？

你的核心理解方向是对的，但漏掉了几个关键的逻辑细节，完整执行流程捋下来是这样：

• 首先shell解析到yes | head命令时，第一步会先创建一个带内核缓冲区的匿名管道，之后分别启动yes和head两个进程：把yes的标准输出绑定到管道写端，把head的标准输入绑定到管道读端，两个进程从这时候开始被系统并行调度运行，这部分和你描述的初始阶段一致。
• 两个进程跑起来之后，yes会无限循环往标准输出写y\n字符串，输出的数据先往管道的内核缓冲区里填充；head默认逻辑是从输入读满10行就主动调用退出逻辑，进程退出时内核会自动回收它持有的所有文件描述符，这时候管道读端的所有引用就都被释放了——这才是触发SIGPIPE的核心前提：管道已经不存在任何存活的读端，没有进程能再读出管道里的数据。如果这时候还有其他进程持有这个管道的读端没关闭，就算head退出了也不会触发信号。
• 你漏掉了很关键的缓冲区环节：不是head一停止运行，yes马上就会收到SIGPIPE。管道本身有大小固定的内核缓冲区（Linux环境下默认一般是64KiB），head退出的时候，缓冲区里大概率还堆着yes之前写进去但没被读完的内容，yes后续的写入会先把这个剩余的缓冲区空间填满，直到下一次发起write()系统调用、想往已经写满且读端全关的管道里塞数据的时候，内核才会给yes投递SIGPIPE信号。
• yes收到SIGPIPE后的默认行为是直接终止进程，到这一步整条管道命令的所有相关进程就都退出了，不会出现yes无限运行占满资源的情况，这也是SIGPIPE机制在管道场景下的核心作用。

额外补充个细节：如果程序自己给SIGPIPE注册了自定义处理函数、收到信号后没有直接退出，那触发信号的那次write()调用会返回失败，错误码置为EPIPE，程序也可以靠这个返回值感知到管道已经断开。

内容的提问来源于stack exchange，提问作者John