Re: inconsistent $? after &

[Martin Kealey]

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, dethrophes@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