Re: weird interaction between builtin cat and trap

[Peng Yu]

On 4/20/22, Chet Ramey <chet.ramey@case.edu> wrote:
> On 4/19/22 10:14 PM, Peng Yu wrote:
>> On 4/19/22, Chet Ramey <chet.ramey@case.edu> wrote:
>>> On 4/19/22 12:30 PM, Peng Yu wrote:
>>>> https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html
>>>>
>>>> That is what is written in the bash manual. "When a command terminates
>>>> on a fatal signal whose number is N, Bash uses the value 128+N as the
>>>> exit status."
>>>
>>> This is non-responsive.
>>
>> Why it is not responsive? You asked why I think the exit status should be
>> 141.
>
> You keep saying the loadable cat should terminate due to SIGPIPE. That
> much is clear. What you have refused to answer is why, and why one exit
> status is better than another.

I did answer it. See below for a reiteration.

>> I answered because bash has this convention. Therefore, it is expected
>> that a builtin command in bash should also follow the same convention.
>> It is odd that bash follows one convention but the builtin follows
>> another convention.
>
> You really don't get it. This is the question:
>
>>> The issue boils down to your desire to have the builtin cat exit due to
>>> SIGPIPE instead of a write error (-1/EPIPE) in one particular case.
>>> You've
>>> never been able to explain exactly why.
>
> You still haven't answered it.
>
>> The error message of "cat: write error: Broken pipe" is also not
>> necessary, as it is expected to receive SIGPIPE in a pipeline command
>> like the following. And if people really want to get that error, they
>> can get it from the exit status 141.
>
> This makes me wonder if you think that the builtin cat is writng an error
> message on receipt of SIGPIPE. It's not.

To a user of cat which treats it as a black box, it is cat that wrote
the error messages. It is certainly not seq, nor head, as there are
only three things in the pipeline seq, cat and head.

Whether the message is printed on receipt of SIGPIPE, I don't know the
detail to tell. Are you saying the internal cat doesn't receive a
SIGPIPE?

>> seq 10000000 | cat | head
>>
>> Processing the message as a string "cat: write error: Broken pipe" is
>> much less programmer-friendly than processing an exit status of 141.
>> Therefore, the behavior of the external cat is more reasonable than
>> the builtin cat.
>
> The same question stands. Why is it useful to distinguish 1 (write error)
> from 141 (SIGPIPE)?

You wrote the bash manual? If so, then you will need to answer why
"Bash uses the value 128+ N as the exit status" as written in the
manual. I am merely following the convention in the manual.

Also, the convention seems to be widely accepted. Therefore, you will
need to answer why the internal cat should not follow instead of I
answer why it should follow it.

https://stackoverflow.com/questions/1101957/are-there-any-standard-exit-status-codes-in-linux

>>> One non-zero exit status is as good
>>> as the next for things like flow control and error handling.
>>
>> I don't think so, if 141 is used, SIGPIPE can be distinguished from
>> other errors. If exit status 1 is always used, then SIGPIPE can not be
>> distinguished from other errors.
>
> Why is it useful to distinguish SIGPIPE? Your program should be prepared to
> deal with write errors. Is there some behavior that's going to be different
> in the two cases?

Again. I've answered. Following the convention in the manual.

Just to be sure we are on the same page. There is a SIGPIPE and a
write error instead of just a write error without SIGPIPE. Do I
understand it right?

>> Whether it follows POSIX is not my point here. Whether it is exactly
>> the same as an external cat is also not my point. My point as
>> explained is that external cat has more reasonable behavior in these
>> two aspects, therefore builtin cat should following them. Had external
>> cat has some bad behaviors, there is no point in following them (but I
>> haven't seen them).
>
> If the external cat has behavior you consider superior, you should use it.
> Or you could modify the builtin cat to have the behavior you prefer.

That is not the question. I am here pointing out the problem of the
internal cat.

-- 
Regards,
Peng