Home / ubuntu / Questions / 733484
Accepted
kenn
Asked: 2016-02-15 04:04:53 +0800 CST

gnome-terminal starts with "grep: write error: Broken pipe" message

  • 772

I am running Ubuntu 14.04.3, it's uptodate. I don't know why, for a few days I began to take grep: write error: Broken pipe message on launching gnome-terminal . It seems to be harmless but it bothers me. How can I debug it?

EDIT: I moved aliases and functions each to separate files such as .bash_aliases and .bash_functions and added a command to load them from .bashrc

 if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
 fi

 if [ -f ~/.bash_functions ]; then
. ~/.bash_functions
 fi

If I don't load .bash_functions problem disappears.

I am trying to find the faulty one by disabling each function one by one.

This one gives me the same error but when I disable it I keep getting the same error, so I may have more faulty functions.

 ls -lt  $PWD| grep ^d | head -1 | cut -b 51- 

 grep:  development
 write error: Broken pipe

I wonder why I begin to take that error.

EDIT2:

I found a similar problem here boken pipe

The root of the problem also seems similar.

I tried the given test command in the link which have the same error:

 bash -c '(while echo foo; do :; done); echo status=$? >&2' |  head
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 foo
 bash: line 0: echo: write error: Broken pipe
 status=0

EDIT3:

Though that unbuffer workaround I posted below as an answer to my own question works, I am not satisfied with it, but my knowledge about debugging is limited. Acoording to this link https://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00080.html it stems from SIGPIPE trap by another task, and this link https://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00154.html pinpoints the exact cause of the problem, it's one of the pam authentication module which I am in trouble with it recently.

bash

2 Answers

  1. There's a great explanation of this problem on this Super User answer: How can I fix a Broken Pipe error?.

    Commands in pipes are run asynchronously: this means that in a pipe such as command1 | command2 there's no guarantee that command1 will end before command2.

    When using [...] | grep | head -n 1, head ends as soon as it has read one line; if this happens before grep has finished writing to the pipe, grep receives a SIGPIPE signal and errors out.

    As explained in the answer below that Super User answer, a workaround is to pipe the output of what's before head in the pipeline to tail -n +1 first, which will ignore the SIGPIPE signal:

    command | tail -n +1 | head -n 1

    But in this case there's not even any need for head, since grep has an option to print only the first match:

    [...] | grep -m 1
    • 4
  2. Best Answer

    After hours of struggling with the problem I found a working workaround (I hope so)

    Problem seems to be deeper and complicated. Many people met the same bug. Fixing it is beyond my coverage.

    Closest workaround posted here how-can-i-fix-a-broken-pipe-error by Andrew Beals at bottom like :

    ls -lt $PWD|dd obs=1M | grep -m 1 ^d | cut -b 51-

    is not neat.

    When I intuited that it's related to pipe buffer I gave a shot to unbuffer command like :

     unbuffer ls -lt $PWD| grep -m 1 ^d | cut -b 51-

    It works well.

    I hope somebody posts the real cause of the problem.

    EDIT: A bash Guru would suggest this simple solution , redirecting stderr to /dev/null 

     ls -lt $PWD 2>/dev/null | grep -m 1 ^d | cut -b 51-
    • 3