bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fflush & close behavior not well-defined


From: Andrew J. Schorr
Subject: Re: fflush & close behavior not well-defined
Date: Thu, 1 Oct 2020 08:43:21 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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