Re: wait -n ignores invalid pids when valid pids are listed (solved!)

[Beer, Mathis]

Am Dienstag, 27. April 2021, 11:45:44 CEST schrieb Robert Elz:
>     Date:        Tue, 27 Apr 2021 05:57:40 +0000
>     From:        "Beer, Mathis" <Mathis.Beer@funkwerk.com>
>     Message-ID:  <3024777.xmhlYjkYgV@ka-nl-mbeer>
> 
>   | Given a background process that has exited before the script got to wait
>   | -n:
>   | 
>   | function foo() { return 1; }
>   | foo & FOO_PID=$!
>   | 
>   | function bar() { sleep 1; }
>   | bar & BAR_PID=$!
>   | 
>   | sleep 0.1
>   | # should exit with 127 since FOO_PID is non-existent now
>   | wait -n $FOO_PID $BAR_PID
> 
> That's not the way it works, pid's "exist" for these purposes until
> waited upon (just as they do in the process table for processes and
> the wait() sys call).
> 
> The exit status should be 1, as that's the exit status of foo.
> 
>   | Then wait -n will wait on BAR_PID to exit, despite the fact that FOO_PID
>   | is
>   | invalid. (Tested with 5.0.17.)
> 
> A second wait -n (in bash) generates a diagnostic about the pid that
> no longer exists (the NetBSD sh which has the same options doesn't do that)
> but waits for anything valid.
> 
>   | The way it currently works makes it hard to make a script that waits for
>   | one of a set of background processes to exit
> 
> Not if you code it properly.  Use -p to help.   It all just works.
> 
>   | (ie. that fails if one of a set of
>   | background processes fails), since any error that happens before the
>   | script
>   | reaches the wait will simply be ignored.
> 
> No, it won't.
> 
> kre

Ah sorry, my first reply got lost cause I didn't do "reply to list" correctly.

Yes, wait -n does the right thing. I hadn't realized at the time that the 
behavior in an interactive shell and a script was different, and all my tests 
were done in an interactive shell.

All is good!