Pipes are implemented with a buffer, so writing to a pipe writes to the buffer immediately if there's space but waits for space to open up if there isn't. Likewise, reading from a pipe reads from the buffer if there's anything in it, but waits for something to be there if there isn't. When the reader has read enough and closes the pipe, a subsequent attempt to write to the buffer will result in SIGPIPE being sent to the writing process, so that it won't keep churning away producing output that nobody will ever read. But if the writer's entire output is already in the buffer by the time the reader finishes, then it will never try to write to the closed pipe and therefore never receive SIGPIPE. So if there's less than one buffer-full of stuff in the dicom_hdr output after the first occurrence of lOffset, it's possible (but not guaranteed) that dicom_hdr will finish writing before grep finishes processing the first occurrence of lOffset. If on the other hand there's more than one buffer-full left for dicom_hdr to output after the point where grep is going to stop reading, then it's guaranteed that grep will close the pipe before dicom_hdr can finish writing, so the SIGPIPE will get sent. So you'll have files where it happens every time, and you'll have files where it happens some of the time unpredictably, and if lOffset is the last line in dicom_hdr's output, you can have a file where it will never happen.