前天用 iTerm2,在执行一个 grep "xxx" filename | head (filename 这个文件应该相当大,grep 到的内容也应该有很多)这样的命令时,遇到大量如下错误输出:
grep: writing output: Broken pipe
而在 Mac 自带的 Terminal.app 里面执行完全一样的命令,不会有任何错误。用 which 查看,使用的确实是同一个 grep 命令,同一个 head 命令。再仔细观察,发现其实 iTerm 里面,命令也输出了正确的结果,那后面的这些错误信息应该是输出到 stderr 的。把命令改成
grep "xxx" filename 2>errors | head
确实,错误信息都跑到 errors 文件里了。这时又发现,在 Terminal.app 里命令在输出10行之后立即结束执行,而在 iTerm 里则取决于这个文件有多大,grep 出来的内容有多少行,它就会执行相应长的时间。网上看到有人说这是 head 取得10行后立即退出,这个 pipe 的读端就没了,grep 继续往 pipe 写,于是 - broken pipe, 只要将错误定向到 /dev/null, 忽略即可。可是我经常用 grep 来在特别大的日志文件里找东西,进行下一步分析前,就先用 head 看看 grep 的正则表达式写的对不对。每次 grep 都不管 head 只读少数行这个现实,一直执行到读完整个文件,太浪费时间和资源了。
... Read full article: grep: writing output: Broken pipe in iTerm2
