[talk] Concisely determining exit codes of background jobs

[Matthew Story]

On Tue, Feb 12, 2019 at 5:56 PM Ipsen S Ripsbusker <
ipsens at ripsbusker.no.eu.org> wrote:

> As a tangent to Ivan's talk, we discussed the merits of checking of exit
> status (or other indicators of success) of parallel calls to scp.
> If I recall correctly, Ivan started multiple background scp processes
> with &, and then he waited for them to complete with the following
> command, which always exits 0.
>
>   wait
>
> The following command waits for the same background processes, and
> it still exits 0 if all processes exited 0. It differs in that it
> exits 1 if any process exited with something other than 0.
>

This isn't quite right. Wait with multiple pids will exit with whatever the
exit code was of the last pid specified so:

$ { sh -c 'sleep 1; exit 1;' & sh -c 'sleep 1; exit 0;' & }; wait `jobs -p`
[1] 237790
[2] 237791
[1]-  Exit 1                  sh -c 'sleep 1; exit 1;'
[2]+  Done                    sh -c 'sleep 1; exit 0;'
$ echo $?
0

More from the spec:

"If one or more operands were specified, all of them have terminated or
were not known by the invoking shell, and the status of the last operand
specified is known, then the exit status of *wait* shall be the exit status
information of the command indicated by the last operand specified."

source: http://pubs.opengroup.org/onlinepubs/007904975/utilities/wait.html



>
>   wait `jobs -p`
>

Why not just use $!?




>
> Note that these are of course the standard wait(1) and jobs(1),
> which are usually builtins in sh(1).
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk
>


-- 
regards,
matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20190213/2694ef5c/attachment.htm>