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
