Re: weird interaction between builtin cat and trap

[Dennis Williamson]

On Thu, Apr 14, 2022 at 5:09 PM Peng Yu <pengyu.ut@gmail.com> wrote:

> On 4/14/22, Chet Ramey <chet.ramey@case.edu> wrote:
> > On 4/14/22 11:14 AM, Jesse Hathaway wrote:
> >> On Thu, Apr 14, 2022 at 9:37 AM Peng Yu <pengyu.ut@gmail.com> wrote:
> >>> This code is the even simpler to reproduce the error.
> >>>
> >>> $ cat ./main.sh
> >>> #!/usr/bin/env bash
> >>> # vim: set noexpandtab tabstop=2:
> >>>
> >>> enable -f "$BASH_LOADABLES_PATH"/cat cat
> >>> trap 'echo EXIT' EXIT
> >>> seq 1000000 | builtin cat | {
> >>>          :
> >>> } {fd}<&0
> >>> $  ./main.sh
> >>> cat: write error: Broken pipe
> >>> EXIT
> >>
> >> I think this is a difference in implementation, rather than a bug.
> >> The builtin cat writes any errors to stdout and exits 1, whereas
> >> cat from coreutils sets its exit code to 141 on receiving a
> >> Broken Pipe(32), but does not write anything to stderr.
> >
> > More or less. The trap has something to do with it, too.
> >
> > The builtin cat catches and reports write errors before it checks for
> fatal
> > signals, including SIGPIPE. The coreutils cat just dies due to SIGPIPE
> > (exit status 141).
> >
> > The trap EXIT causes bash to install a signal handler for the fatal
> > signals, including SIGPIPE. (All it does is clean up, run the exit trap,
> > and resend the signal to itself. And in this case the child running
> > cat doesn't run the exit trap, so it's just a passthrough.)
> >
> > The coreutils cat doesn't do that. It may or may not check for write
> > errors, but it certainly doesn't catch SIGPIPE. It terminates before it
> > even has a chance to check for write errors.
>
> Shouldn't you make the builtin cat behave the same as the external
> cat? 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.
>
> 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.
>
> --
> Regards,
> Peng
>
>
From
http://git.savannah.gnu.org/cgit/bash.git/tree/examples/loadables/README?h=devel
:

cat.c           cat(1) replacement with no options - the way cat was intended.


Which implies to me that it should not be expected to duplicate coreutils
cat. It doesn't speak to whether there might be bugs, however.
-- 
Visit serverfault.com to get your system administration questions answered.