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
