Re: weird interaction between builtin cat and trap

[Chet Ramey]

On 4/15/22 10:03 AM, Peng Yu wrote:
> On 4/15/22, Chet Ramey <chet.ramey@case.edu> wrote:
> > On 4/14/22 6:08 PM, Peng Yu wrote:
> >
> > > Shouldn't you make the builtin cat behave the same as the external
> > > cat?
> >
> > It already doesn't: it has no options and I'm uninterested in adding any.
>
> I am clearly talking about calling cat without options based on the context.
>
> builtin cat clearly doesn't support those options that are supported
> by the external cat. So people will not use the builtin cat as a
> drop-in replacement for the external cat.

So then why whinge about it behaving differently from the external cat?
It's already different.

> But for no option cat, the builtin cat is similar to the external cat
> enough so that it is a reasonable expectation that they should behave
> the same.

The `same behavior' here is dying due to SIGPIPE before checking for a
write error. Is that the hill you're dying on?


> > In most cases, where the behavior is standardized, that's the case, but I
> > wrote the builtin cat as an homage to Pike's "cat -v considered harmful"
> > paper (http://harmful.cat-v.org/cat-v/unix_prog_design.pdf).
>
> That is exactly why I bring up this case of builtin cat and why this
> problem should be fixed. There is no excuse to dismiss a bug as a
> feature once it is known.

You really think checking for a write error first is a bug? I urge you to
reassess your priorities if you have a use case where the type of fatal
error makes a significant difference.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/