Hi Chet,
Thank you for the response.
If I read it correctly you agree that this is a regression from how
it worked previously?
I am not a very experienced C programmer, so I am a little bit hesitant
to dive into the code to try to fix it myself. However, I am not certain
on how to proceed from here. Would you like me to try to see if I can
figure out a solution, or is this better handled in a more organized way by
people with the appropriate know how?
Best regards
Jonas
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, May 16, 2021 6:46 PM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 5/13/21 3:44 PM, Jonas Alfredsson via Bug reports for the GNU Bourne
> Again SHell wrote:
>
> > Bash Version: 5.1
> > Patch Level: 0
> > Release Status: release
> > Description:
> > If one has a script similar to this:
> >
> > trap 'echo "Received SIGHUP"' HUP
> >
> > sleep 5m &
> > child_pid=$!
> >
> > wait -n ${child_pid}
> > wait -n ${child_pid}
> >
> >
> > and you send in the system signal SIGHUP the first `wait` will exit (as
> > expected)
> > and the message "Received SIGHUP" will be printed. However, since we have a
> > second `wait` it should catch further execution and wait for the child once
> > again.
>
> Thanks for the report. The issue is a change between bash-5.0 and bash-5.1
> to understand PID arguments with -n. The job state wasn't restored upon
> receipt of all trapped signals and interfered with subsequent calls to
> `wait -n'.
>
> 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://tiswww.cwru.edu/~chet/
