Re: weird interaction between builtin cat and trap

[Peng Yu]

On 4/15/22, Peng Yu <pengyu.ut@gmail.com> wrote:
> 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

I forgot to mention the exit status. Here are the status of the above command.

$ declare -p PIPESTATUS
declare -a PIPESTATUS=([0]="141" [1]="1" [2]="0")

Here is that of external cat. The error should be catched in the exit
status as 141 instead of printing an error message and return 1.

$ seq 10000000 | exec cat | head
1
2
3
4
5
6
7
8
9
10
$ declare -p PIPESTATUS
declare -a PIPESTATUS=([0]="141" [1]="141" [2]="0")

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


-- 
Regards,
Peng