git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 10, 2013, 00:39 UTC
Message-ID
<7vobgx3m8o.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20130110001844.GC21054@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 5 quoted lines
> I'm not sure whether there are SIGPIPE instances we really don't want
> to be silent about, though.  I suspect not. ;-)
>
> Compare <http://thread.gmane.org/gmane.comp.version-control.git/2062>,
> <http://thread.gmane.org/gmane.comp.version-control.git/48469/focus=48665>.
Yeah, thanks for the pointer to 48665.  Quoting from there:
    So EPIPE really _is_ special: because when you write to a pipe,
    there's no guarantee that you'll get it at all, so whenever you get
    an EPIPE you should ask yourself:
     - what would I have done if the data had fit in the 64kB kernel
       buffer?
     - should I really return a different error message or complain just 
       because I just happened to notice that the reader went away
       _this_ 
       time, even if I might not notice it next time?
    In other words, the "exit(0)" is actually _more_ consistent than
    "exit(1)", because exiting with an error message or with an error
    return is going to depend on luck and timing.
and I think I still agree with the analysis and conclusion:
    So what _should_ you do for EPIPE?
    Here's what EPIPE _really_ means:
     - you might as well consider the write a success, but the
       reader isn't actually interested, so rather than go on, you
       might as well stop early.
    Notice how I very carefull avoided the word "error" anywhere.
    Because it's really not an error. The reader already got
    everything it wanted. So EPIPE should generally be seen as an
    "early success" rather than as a "failure".
Previous: Jonathan NiederNext: Jeff King
Message 16 of 23 in “avoid SIGPIPE warnings for aliases”
  1. avoid SIGPIPE warnings for aliasesJeff King, Jan 4, 2013
  2. Johannes SixtJan 4, 2013
  3. Jeff KingJan 4, 2013
  4. Junio C HamanoJan 4, 2013
  5. Jeff KingJan 5, 2013
  6. run-command: encode signal death as a positive integerJeff King, Jan 5, 2013
  7. Johannes SixtJan 5, 2013
  8. Jonathan NiederJan 5, 2013
  9. Jeff KingJan 5, 2013
  10. Jonathan NiederJan 5, 2013
  11. Junio C HamanoJan 6, 2013
  12. Junio C HamanoJan 9, 2013
  13. Jeff KingJan 9, 2013
  14. Junio C HamanoJan 9, 2013
  15. Jonathan NiederJan 10, 2013
  16. Junio C HamanoJan 10, 2013
  17. Jeff KingJan 10, 2013
  18. Junio C HamanoJan 10, 2013
  19. Jeff KingJan 10, 2013
  20. Johannes SixtJan 10, 2013
  21. Junio C HamanoJan 10, 2013
  22. Jeff KingJan 10, 2013
  23. mimimimiJul 21, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.