Re: weird interaction between builtin cat and trap

[Peng Yu]

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.

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.

128+n exit status for signal n is also mentioned below. Therefore, it
is reasonable to expect a builtin to follow the same convention.

https://tldp.org/LDP/abs/html/exitcodes.html

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

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.

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.

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

> Your program, or whatever it is, should be able to deal with error
> messages written to stderr, so it can't be that. Exact compatibility with
> the external /bin/cat is not a requirement, nor is POSIX conformance.
> There aren't any bugs here.

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

Whether you call the two problems of builtin cat as "bug" or not, is
subjected to the definition of "bug". But bug-vs-features problem is
subjected to human interpretation. In this sense, if you don't think
it should be changed as it is not a "bug". Of course, people can live
with this "feature".

However, I do think making a builtin cat the same as the external cat
in these two aspects is an improvement instead of a deterioration.

Also, if built-in cat is not supposed to be the same as the external
cat in these two aspects, why call them the same name? Having the same
name makes people think that one is the drop-in replacement (except
for speed) for the other for no-command-line-arg usage. When there is
such a difference, shouldn't they be called two different names to
avoid confusion?

-- 
Regards,
Peng