I wrote:
> Description:
> The value of $? after starting a backgrounded command is inconsistent:
> $? is unchanged after starting a sufficiently complex command, but
> after starting a simpler command it is set to 0.
> From: Chet Ramey
> Thanks for the report. The exit status of any asynchronous command is 0.
> I will fix this for bash-4.3-release.
>
On Sat, 14 Dec 2013, dethrop...@web.de wrote:
> I thought the value was only 0 if the fork/spawn was succesful.
> i.e. if it fails for lack of resources or something it's non zero.
>
> or have I miss understood it's [sic] significance?
I'm inclined to agree; there seems little point in arbitrarily always
setting it to 0, when it could be used to provide information -- either the
success-or-failure of the fork() (or spawn()), or simply retaining the
previous status.
While on the subject of exit status, any chance of being able to wait on a
list of processes (or "any"), and get back the exit status and pid of the
next one to finish? And to find out status of a stopped job? And to
distinguish between an exit status of 129 and SIGHUP?
(That lack had me rewriting a significant chunk of code in Perl when it was
otherwise nearly finished in Bash.)
I'm thinking of these additions:
wait -o [JOB ...]
wait for one child process out of the given list, or for any single child
process if no list is given.
sets $! to the pid of a child process which has terminated (or stopped), and
sets $? in the normal manner pertaining to that process
if no child process can be waited for, unsets $! and sets $? to 1 for ECHILD
or 2 for EAGAIN
if waiting for one-of-many but not "any" is unsupported, unsets $! and sets
$? to 3
(-o is implied if one or more JOBs are given)
wait -e
shopt -s exitstatus
when a child process is terminated or stopped by a signal, set $? to zero
minus the signal number (rather than 128 plus the signal number), so that the
full 8-bit range of exit statuses are distinguishable
wait -t
implies -o
report a child process which has stopped or terminated
sets $? to indicate the signal which cause the process to stop or terminate
wait -tt
like -t, but only report on a child process which has stopped, not terminated
sets $? to 3 if unsupported by the OS
Names for options are negotiable, but I chose to avoid '-s' because it's
rather ambiguous in this context: single? signal? status? stopped? Long
option names might also be nice.
Waiting for multiple processes (but not all) presents some challenges; Perl
implements this by waiting for all, and stashing the statuses until the
script actually waits for them.
-Martin
