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: Chet Ramey
Subject: Re: weird interaction between builtin cat and trap
Date: Wed, 20 Apr 2022 10:24:52 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.0

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


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

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


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

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



reply via email to

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