Yes, this is the part that I agree. However, this is the other behavior of
bash wait (from bash manual)
"When Bash is waiting for an asynchronous command via the wait builtin, the
reception of a signal for which a trap has been set will cause
the wait builtin to return immediately with an exit status greater than
128, immediately after which the trap is executed."
The behavior is the same for when parent or child receives the signal. When
it's the parent process that received it, child might still be running. It
simply breaks the logic of wait. In order to wait until the child exits
even when signal was received, I need to implement a new wait command (with
some hacks) like this (untested):
usr1(){
got_signal=true
Do something...
}
wait2() {
while true; do
got_signal=false
wait $*
exitcode=$?
$got_signal || return $exitcode
}
trap usr1 USR1
( Child stuff... Send USR1 to parent ) &
wait2 $!
Em sex, 30 de set de 2016 09:45, Chet Ramey <chet.ra...@case.edu> escreveu:
> 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 c...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
--
Luiz Angelo Daros de Luca
luizl...@gmail.com
