Re: Possible regression in 'wait' command

[Jonas Alfredsson]

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 <kre@munnari.OZ.AU> wrote:

> Date: Thu, 13 May 2021 23:52:20 +0200
> From: Alex fxmbsw7 Ratchev fxmbsw7@gmail.com
>
>     Message-ID:  
> <CAALKErENP9Jv2s29WiCM-AYe0as64QXFGT6NVF6BxGGt3BizzA@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