Re: fflush & close behavior not well-defined

[arnold]

I have no explanation. Maybe Chet does.

In the meantime I've updated the repo.

Arnold

"Andrew J. Schorr" <aschorr@telemetry-investments.com> wrote:

> On Wed, Sep 30, 2020 at 11:12:38PM -0600, arnold@skeeve.com wrote:
> > Why does it matter?  Remember that the string that can be used for
> > pipelines can be any shell command. Gawk runs /bin/sh to execute the
> > command; the exit status that comes back *is that of the shell*, not
> > of the command it runs!
>
> True.
>
> > To wit, if we modify your one-line slightly by using exec:
> > 
> > $ cat x.awk
> > BEGIN { LINT = 1 }
> > BEGIN {print "hello" |& "exec cat"; print close("exec cat")}
> > 
> > On Fedora:
> > 
> > $ ./gawk -f x.awk
> > gawk: x.awk:2: warning: failure status (269) on two-way pipe close of `exec 
> > cat': Success
> > 269
> > 
> > And now on Ubuntu:
> > 
> > $ ./gawk -f x.awk 
> > gawk: x.awk:2: warning: failure status (269) on two-way pipe close of `exec 
> > cat': Success
> > 269
> > 
> > Ta da!
> > 
> > The previous 141 came from bash, where:
> > 
> > 1. The exit status of the shell is the status of the last command it ran
> > 2. If the command exited upon signal, the status is 128 + the signal number
>
> Interesting.
>
> > I *knew* that that was going on somewhere!
> > 
> > Apparently Bash changed at some point, from passing up the unadulterated
> > wait(2) exit status, to working as just described.
> > 
> > I will see if I can adjust the test.
>
> But I still don't understand the inconsistency in strace output. In my
> test, I saw this:
>
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=3899, si_uid=300, 
> si_status=SIGPIPE, si_utime=0, si_stime=0} ---
>
> And when you ran strace, you got this:
>
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=29075, si_uid=1000, 
> si_status=141, si_utime=0, si_stime=0} ---
>
> Notice that my child process exited due to the signal with CLD_KILLED, whereas
> yours exited with CLD_EXITED. One child bash shell exited due to SIGPIPE,
> whereas the other seems to have trapped it and then exited in a more orderly
> fashion, I guess.  I don't know whether this is a race condition or some other
> subtle issue relating to which child process received the SIGPIPE (bash vs 
> cat).
>
> Regards,
> Andy