Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Stephane Chazelas <stephane.chazelas-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Re: [1003.1(2008)/Issue 7 0000789]: Add set -o pipefail
Newsgroups: gmane.comp.standards.posix.austin.general
Date: Saturday 30th May 2015 07:58:49 UTC (about 1 year ago)
2015-05-29 22:47:05 -0500, Rob Landley:
> On Fri, May 29, 2015 at 5:08 PM, Stephane Chazelas
>  wrote:
> > 2015-05-29 22:45:31 +0100, Pádraig Brady:
[...]
> >> Well another reason for having SIGPIPE over write returning EPIPE,
> >> is that one can distinguish the signal exit status (WIFSIGNALED).
> >> The shell should handle this specially and not exit 141 in this case.
> >> (as it does normally with a straight: seq 10000 | head && echo ok
> > [...]
> >
> > Alright, sorry I thought the discussion was about the pipefail
> > implementation treating "dying of sigpipe" as a non-error
> > condition, as opposed to utilities returning 0 when failing to
> > write on a broken pipe.
> >
> > I don't like that idea.
> >
> > Failing to write should be an error condition.
> 
> Given that "yes" produces endless output, you're saying it should
> never be possible for it to exit with a non-error condition?
[...]

Well, yes, "yes" can never manager to write all its output, it
will either die of a signal (SIGPIPE, SIXCPU, SIGINT...) or a
write error (disk full, broken pipe, file too big, quota
exceeded...)

The point is that there's generally little point *checking* its
exit status (except maybe to discriminate between the different
error conditions), not that its exit status should be changed to
always mean success instead of failure.

If we want pipefail to not be affected  by SIGPIPE, then the
burden of implementing that would be on the pipefail feature in
the shell, not in the utilities to work around the shell's
pipefail implementation defficiency.

If you wan't to ignore pipefail for a specific pipeline
component, then, you could do:

set -o pipefail
(trap - PIPE; yes || [ "$(kill -l -- "$?") = PIPE ]) | head |
whatever

Now, that's where the issue I just raised with builtins becomes
a real problem, since that wouldn't work for builtins.

-- 
Stephane
 
CD: 3ms