Re: Racing condition leads to unstable exit code

[Chet Ramey]

On 9/29/16 10:58 PM, Luiz Angelo Daros de Luca wrote:
> No problem! I already workarounded it using pipe as a semaphore. Thanks!
> 
> It's there any chance of changing the 128+signal exit code for wait when
> trap is received?
> It might solve some special usecase which I'm not aware. Wait should always
> returns exit code related to the child process, except for 127.

The shell is required to do this, and it's historical shell behavior.  If
a process is killed by signal N, its exit status is 128+N.  That's how
scripts know their children were killed due to a signal.


> The 128+signal behavior is not even mentioned on wait documentation but on
> signal section! If wait returns 129, I don't know wether child died because
> of signal 1 (128+1) or if it is the current instance that received the
> signal instead. 

Posix says:

"When the shell is waiting, by means of the wait utility, for asynchronous
commands to complete, the reception of a signal for which a trap has been
set shall cause the wait utility to return immediately with an exit status
>128, immediately after which the trap associated with that signal shall be
taken."

If you want the shell to be insulated from signals that might be sent to
its children, you either have to use job control, which works for the
keyboard-generated signals that go to process groups, or ignore the signal
using trap to be sure you don't receive it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/