Hi Robert, Thank you for your response.
> Don't use non standard command extensions > in test scripts like this. Apologies, this is my first reported issue for Bash, so this was just a number I used to have plenty of time when experimenting by myself. I will keep this in mind in the future. > I tested with the following script [...] That is a much more compact version of what I came up with, really nice! I will see if I can add this to my repository where, through Docker, you can test out both versions of Bash if you like. I am a little bit unsure of how this mailing list works, if everyone gets every mail, but I also got a response from Chet Ramey, whom I will ask how we best move forward in perhaps getting this fixed. Best regards Jonas ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, May 14, 2021 5:45 AM, Robert Elz <k...@munnari.oz.au> wrote: > Date: Thu, 13 May 2021 23:52:20 +0200 > From: Alex fxmbsw7 Ratchev fxmb...@gmail.com > > Message-ID: > <caalkerenp9jv2s29wicm-aye0as64qxfgt6nvf6bxggt3bi...@mail.gmail.com> > > > |https://www.ibm.com/support/pages/exit-code-127-means-jobs-command-can-not-be-found-or-executed > > I have no idea what info that reply was > intended to add, but it us not useful. > > | On Thu, May 13, 2021, 23:10 Jonas Alfredsson via Bug reports for the GNU > | Bourne Again SHell bug-bash@gnu.org wrote: > | > If one has a script similar to this: > > | > trap 'echo "Received SIGHUP"' HUP > | > > | > sleep 5m & > > Don't use non standard command extensions > in test scripts like this. If you cannot > work out the number of seconds in 5 mins > you can use $(( 5 * 60 )) but that is really > too long. 60 secs is plenty, 20 would do. > > | > child_pid=$! > | > > | > wait -n ${child_pid} > | > wait -n ${child_pid} > > | > 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. > > Yes, it should, assuming you send the HUP to > the shell pid, and not to the process group > > | > This is how it works in Bash 5.0.x, > > I no longer have one of those to test, but > I do have bash 4, and it worked there too. > > | > Unfortunatly I do not know the low level stuff well enough to > | > even know where to begin debugging this, > > Start by sprinkling jobs -l commands > at relevant places, that confirms that > the sleep command is still running and > still hasan entry in the jobs table. > > I tested with the following script > > trap 'echo "Received SIGHUP"' HUP > > sleep 60 & > child_pid=$! > > jobs -l > wait -n ${child_pid} > echo wait1 $? > jobs -l > wait -n ${child_pid} > echo wait2 $? > jobs -l > > and ran that as > > bash -x /tmp/b & sleep 5; kill -1 $! > > That shows the issue clearly. > > My guess is that perhaps the first wait > command is setting some state on the job > indicating it has been waited upon, which > is not being cleared when that wait aborts. > > But that is just a guess, I have not looked > at the bash code. > > kre
