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.b...@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!
