Seeing "Broken pipe" in this situation is rare, but normal.
When you run type rvm | head -1
, bash executes type rvm
in one process, head -1
in another.1 The stdout of type
is connected to the "write" end of a pipe, the stdin of head
to the "read" end. Both processes run at the same time.
The head -1
process reads data from stdin (usually in chunks of 8 kB), prints out a single line (according to the -1
option), and exits, causing the "read" end of the pipe to be closed. Since the rvm
function is quite long (around 11 kB after being parsed and reconstructed by bash), this means that head
exits while type
still has a few kB of data to write out.
At this point, since type
is trying to write to a pipe whose other end has been closed – a broken pipe – the write() function it caled will return an EPIPE error, translated as "Broken pipe". In addition to this error, the kernel also sends the SIGPIPE signal to type
, which by default kills the process immediately.
(The signal is very useful in interactive shells, since most users do not want the first process to keep running and trying to write to nowhere. Meanwhile, non-interactive services ignore SIGPIPE – it would not be good for a long-running daemon to die on such a simple error – so they find the error code very useful.)
However, signal delivery is not 100% immediate, and there may be cases where write() returns EPIPE and the process continues to run for a short while before receiving the signal. In this case, type
gets enough time to notice the failed write, translate the error code and even print an error message to stderr before being killed by SIGPIPE. (The error message says "-bash: type:" since type
is a built-in command of bash itself.)
This seems to be more common on multi-CPU systems, since the type
process and the kernel's signal delivery code can run on different cores, literally at the same time.
It would be possible to remove this message by patching the type
builtin (in bash's source code) to immediately exit when it receives an EPIPE from the write() function.
However, it's nothing to be concerned about, and it is not related to your rvm
installation in any way.
1I have been piping the output of
ls
throughhead -1
for years, and today I'm getting a broken pipe message. – Tulains Córdova – 2015-02-23T14:07:38.1971(Note: The "Broken pipe" error doesn't come from the signal. It comes from the errno. While the shell may otherwise show text messages for signal-induced-exits, it's usually smart enough to pretend that a SIGPIPE exit was a 'clean' one.) – user1686 – 2016-09-24T14:22:29.987
Thank you! I was worried about it. I did about an hours worth of googling last night troubleshooting my rvm install and doing repairs to it trying to fix it. I'd just swapped out with an SSD drive and use LVM and encrypted the hard drive so there was a lot of variables coming into play and I just wasn't sure what might have went sideways. Thank you for putting my mind at ease! – Jason Shultz – 2013-02-20T16:43:34.810