Hi,
> Am 30.09.2016 um 16:11 schrieb Luiz Angelo Daros de Luca <luizl...@gmail.com>:
>
> 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):
I don't know the process set up you want to achieve, but maybe it helps when
you send the signal to the complete process group, and not only the parent
process. Specifying a negative PID to `kill` will initiate this.
-- Reuti
>
> 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
>
