help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: weird interaction between builtin cat and trap


From: Peng Yu
Subject: Re: weird interaction between builtin cat and trap
Date: Fri, 15 Apr 2022 13:34:25 -0500

On 4/15/22, Chet Ramey <chet.ramey@case.edu> wrote:
> 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?

The point is that this error for builtin cat 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.

$ seq 10000000 | cat | head
1
2
3
4
5
6
7
8
9
10
cat: write error: Broken pipe

>>> 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/
>


-- 
Regards,
Peng



reply via email to

[Prev in Thread] Current Thread [Next in Thread]