return code 127 by not found cmd or job .. ? On Sun, May 16, 2021, 22:08 Jonas Alfredsson < jonas.alfreds...@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 <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 > > >
