Re: weird interaction between builtin cat and trap

[Andreas Kusalananda Kähäri]

On Tue, Apr 19, 2022 at 12:01:40PM -0500, Peng Yu wrote:
> On 4/18/22, Chet Ramey <chet.ramey@case.edu> wrote:
> > On 4/15/22 2:34 PM, Peng Yu wrote:
> >
> >>> The `same behavior' here is dying due to SIGPIPE before checking for a
> >>> write error. Is that the hill you're dying on?
> >>
> >> The point is that this error for builtin cat should be ignored.
> >
> > So EPIPE should be ignored.
> >
> >> Another way to demonstrate the problem is the even simpler code. There
> >> is no point to generate this kind of error. Otherwise, the external
> >> cat would have done so already.
> >
> > This is just another example of the same scenario.
> > There's nothing new
> > here.
> 
> Yes and no. "No" in the sense, that `some_command_general_long_output
> | cat | head` is a common enough use case for with SIGPIPE error
> should not result in an error message. Users mostly likely don't want
> to see the SIGPIPE error message but just the first 10 lines output by
> head.

Your original pipeline looked like

        some_command | cat | { seq 10 | while read ...; }

Note that the cat there blocks until the seq command finishes, and then
writes to a pipe that nobody listens to.  Then it dies from the SIGPIPE
that this results in.

If I misunderstood the flow there, then I might possibly be forgiven to
say that what started this thread was not a common use case.

> 
> > You want SIGPIPE-before-write-error behavior and the builtin cat
> > doesn't do things in that order.
> 
> -- 
> Regards,
> Peng

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.