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@xxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
