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

Re: [PATCH] Don't ignore write failure from git-diff, git-log, etc.

From
MRMarco Roeland <marco.roeland@xs4all.nl>
Date
May 28, 2007, 19:05 UTC
Message-ID
<20070528190529.GA10656@fiberbit.xs4all.nl>
In-Reply-To
<87646cx13d.fsf@rho.meyering.net>
On monday May 28th 2007 at 20:19 Jim Meyering wrote:
> ...
> 
> Also, to be consistent, don't ignore EPIPE write failures.

In practice I agree with someone else on this thread that EPIPE _is_ different. In a way the responsibility doesn't lie with the writer but with the reader.

But just out of curiosity is there an easy way to test the EPIPE behaviour? I cite a piece of the "changelog.Debian" file from the Debian version of the bash shell. In Debian, as earlier in many other distributions, the annoying EPIPE error was "fixed" in version 2.0.3-3 from 19 dec 1999.

========================================================================
* Define DONT_REPORT_SIGPIPE: We don't want to see `Broken pipe' messages
  when a job like `cat jobs.c | exit 1' is executed. Fixes part of #7047,
  #10259, #10433 and #10494. Comment from the upstream author: "The default
  bash behavior with respect to the exit status of a pipeline will not
  change.  Changing it as suggested in the discussion of #10494 would render
  bash incompatible with every other shell out there.". Closed these reports.
  -- Matthias Klose <doko@debian.org>  Sun, 19 Dec 1999 15:58:43 +0100
========================================================================

The mentioned "test-case" as used in "git log -n1 | exit 1" doesn't produce an error in my Debian 'sid' bash, either with or without your patch, so it doesn't seem to have any effect there? Whereas probably in a "default" bash (don't know if upstream has changed it's mind already!) with your patch (i.e. the EPIPE special casing removal) it will again probably introduce these annoying (for interactive use) errors.

Thanks for your patch anyway, the "fcntl" diagnosis is a really useful technique to know, and IMVHO also useful for git; although perhaps not very portable for all platforms.

-- 
Marco Roeland
Previous: Jim MeyeringNext: Jim Meyering
Message 10 of 29 in “Don't ignore write failure from git-diff, git-log, etc.”
  1. Don't ignore write failure from git-diff, git-log, etc.Jim Meyering, May 26, 2007
  2. Linus TorvaldsMay 26, 2007
  3. Junio C HamanoMay 26, 2007
  4. Nicolas PitreMay 27, 2007
  5. Jim MeyeringMay 27, 2007
  6. Linus TorvaldsMay 27, 2007
  7. Jim MeyeringMay 28, 2007
  8. Marco RoelandMay 28, 2007
  9. Jim MeyeringMay 28, 2007
  10. Marco RoelandMay 28, 2007
  11. Jim MeyeringMay 28, 2007
  12. Petr BaudisMay 28, 2007
  13. Junio C HamanoMay 28, 2007
  14. Jim MeyeringMay 29, 2007
  15. Junio C HamanoMay 29, 2007
  16. Jim MeyeringMay 30, 2007
  17. Linus TorvaldsMay 28, 2007
  18. Jim MeyeringMay 28, 2007
  19. Linus TorvaldsMay 29, 2007
  20. Jim MeyeringMay 29, 2007
  21. Linus TorvaldsMay 29, 2007
  22. Jim MeyeringMay 30, 2007
  23. Linus TorvaldsMay 30, 2007
  24. Jim MeyeringMay 30, 2007
  25. Junio C HamanoMay 28, 2007
  26. Linus TorvaldsMay 29, 2007
  27. Jim MeyeringMay 30, 2007
  28. Junio C HamanoMay 30, 2007
  29. Jim MeyeringMay 30, 2007

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.