Marco Roeland <marco.roeland@xxxxxxxxx> wrote:
> 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.
Do you think it's ok for git-rev-list _not_ to diagnose an erroneous
command like this (i.e., to exit(0)):
git-rev-list HEAD | sync
where "sync" could be any command that exits successfully
without reading any input?
Is it ok that it is currently *impossible* to diagnose that
failure by looking at exit codes?
> 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
There are some examples here:
http://thread.gmane.org/gmane.comp.version-control.git/48469/focus=48617
...
> 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.
As I just said in reply to Linus, the EPIPE handling difference
is independent of what version of bash you use.
> 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.
It appears to be portable enough. fcntl/F_GETFD support is required
by POSIX, and has been around for ages. FWIW, it's also used in git's
daemon.c and sha1_file.c.
-
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
