Re: Possible regression in 'wait' command

[Alex fxmbsw7 Ratchev]

return code 127 by not found cmd or job
.. ?

On Sun, May 16, 2021, 22:08 Jonas Alfredsson <
jonas.alfredsson@protonmail.com> wrote:

> 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
>
>
>