Re: Racing condition leads to unstable exit code

[Luiz Angelo Daros de Luca]

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 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. The worse is that I cannot even trap this signal as wait has precedence. And all depends on timing, if received before wait (which trap takes care) of after it returning the wait call. I think that using wait for catching signals is somehow abusing it, specially when comparing with wait (2) call.

Regards,

Thanks!

Em qui, 29 de set de 2016 16:39, Chet Ramey <chet.ramey@case.edu> escreveu:

On 9/23/16 3:04 PM, Luiz Angelo Daros de Luca wrote:
> Hello,
>
> I'm using 'GNU bash, version 4.3.46(1)-release (x86_64-suse-linux-gnu)'
> provided by OpenSUSE Tumbleweed. I recently faced a problem that, depending
> on the system load, bash returns different exit codes. I detected that it
> is related to trap processing.

Thanks for the report.  It is related (indirectly) to trap processing in
that traps get processed while reading the command substitution output.
The problem still exists in bash-4.4, and I will probably release a
bash-4.4 patch to address it.  There are a few things ahead of that in
the queue, though.

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/

--

Luiz Angelo Daros de Luca
luizluca@gmail.com