Re: sort is overeager at reporting I/O errors

[Tom Lord]

I wasn't ignoring the request -- just waiting for the time to Do It
Right, which will take a few more days, at least.  

In the meantime, though, I'll give a quick elaboration because, since
sending the report, I've discovered that the problem is more
complicated than I thought and might actually be a bug in my
"/bin/sh".

        % sort --version
        sort - GNU textutils 1.14  
        (seemingly no relevant changes in 2.0, though)

        % uname -a
        ...FreeBSD 3.0-RELEASE #18 ... i386

        shell:
        Ash


Here is the bug:
Suppose I write a shell script `cause-bug' containing:


        set -e
        for f in blah blah blah ; do
            prog $f
        done

In another script, `show-bug', I have:

        cause-bug | head -n 1

Eventually `prog' will either get an EPIPE (and hopefully exit with
non-0 status) or die on SIGPIPE, depending on the state of its signal
mask.  What should happen is that `cause-bug' silently exits at that
point with non-0 status.  What does happen is that a "broken pipe"
message appears on stderr, sometimes apparently from the `prog' (and I
think this was the case with `sort') and sometimes from the shell.

Looking at the `sort' source code, I concluded that `sort' was
ignoring SIGPIPE, therefore getting EPIPE, and was producing an error
message on stderr for any kind of output error -- it would be better
to treat EPIPE as a special case and not produce a message.

Unfortunately, since sending the original report I've seen an error
message for a different program, `sed' (not GNU sed) and that
implementation of `sed' most definitely does absolutely nothing
special with SIGPIPE.  So, either there is a coincidence here where
the error messages from the shell look exactly like the error messages
from `sort' and `sed' (including the part which is not strerror text),
hence the bug is entirely in the shell, or the shell is execing these
processes with SIGPIPE masked (in which case, in my opinion, the shell
has the larger bug, but treating EPIPE specially in `sort' and `sed'
would be an improvement.

I realize that treating EPIPE and SIGPIPE specially is an odd
conclusion.  My contention is that those errors mean "output is not
being read -- you can exit now" and that they do not mean "something
has gone disastrously wrong, please spew to stderr".  Unless
{SIG,E}PIPE are thought of in that way, it is impossible to write an
otherwise reasonable script like `cause-bug' and that seems just plain
wrong to me.

-t