Re: weird interaction between builtin cat and trap

[Peng Yu]

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.

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.

>> I'd expect the built-in command to be a drop-in replacement of
>> the corresponding external command, as using builtin is to speed up
>> the bash program but not to change its behavior.
>
> 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.

>> https://simplicable.com/new/bug-vs-feature
>> - Bug: Something that can be reasonably viewed as a problem based on
>> current requirements....
>> - Feature: Something that hasn't been requested in current
>> requirements....
>>
>> According to the above definition of bug vs feature, it should be
>> considered as a bug meaning the behavior is not consistent with the
>> corresponding external program.
>
> You presume too much about the "current requirements."

I don't think so. The requirement should be based on logical reasoning
instead of some prior standard like POSIX. builtin cat is not even in
POSIX any way.

-- 
Regards,
Peng