[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
- Re: fflush & close behavior not well-defined, arnold, 2020/10/01
- Re: fflush & close behavior not well-defined,
Andrew J. Schorr <=
- Re: fflush & close behavior not well-defined, arnold, 2020/10/01
- Re: fflush & close behavior not well-defined, Andrew J. Schorr, 2020/10/01
- Re: fflush & close behavior not well-defined, Chet Ramey, 2020/10/01
- Re: fflush & close behavior not well-defined, arnold, 2020/10/01
- Re: fflush & close behavior not well-defined, Chet Ramey, 2020/10/01
- Re: fflush & close behavior not well-defined, arnold, 2020/10/02
Re: fflush & close behavior not well-defined, Chet Ramey, 2020/10/01