Re: [arch-users] Re: EPIPE in standard utils ([issue41])

[Tom Lord]

[As an aside ... just repeating things from another GNU list ...
 I had a brain bug about the timing of signal delivery and was
 thinking that sed could actually both be getting a (yet undelivered)
 SIGPIPE and (meanwhile) spewing about EPIPE on stderr.  In fact (and, 
 of course, in retrospect) SIGPIPE should arrive as the errant syscall
 returns and (with the default handler) terminate the process before 
 the stderr spew has a chance to occur.   So the bugs my users are
 seeing are (presumably) bugs in whatever shell they're using for 
 execing with SIGPIPE masked.   My bad.  I'll be embarassed for a
 month over forgetting how signal delivery works.]


        I don't see why an EPIPE on stdout or some other descriptor
        other than stderr itself should not produce an error message
        on stderr. After all, EPIPE is an *error* and that's what
        stderr is good for.


Well, now that I remember how signal deliver works, I pretty much
agree -- a pedantic improvement in various utils _might_ be to make 
sure that SIGPIPE has default behavior but, really, I'm now turning my
attention to why the shell in question is screwing up.

I haven't found, BTW, anything in POSIX that actually guarantees that
SIGPIPE will be delivered during the return from the syscall that
generates it -- it's just how BSD and Linux both seem to work.   I can
imagine systems that would work differently, though I don't know of
any that do in practice.   The point being that _formally_, just going
by the language in Posix, it would seem that you can't rely on timely
delivery of SIGPIPE and, in that context, my comments about treating
EPIPE specially make some sense if you want a sane environment for
shell programming.

      > and, at least arguably,
      > should exit with 0 status on EPIPE to an output file.

      Definitely not. Utilities (like sed) that write data to some
      output file as part of their specified job should never exit
      with an "OK" status on EPIPE (or any other error
      condition). That's an *error* that prevents them from doing
      their specified job properly, which is definitely *not* "OK".

If you take the literal reading of Posix in which timely SIGPIPE isn't
guaranteed, then EPIPE _must_ be treated as I suggested or else shell
programming is screwed.  It's only the extra-standard factoid that
timely delivery is reasonably expected that changes the circumstance.

-t