Bash – Is “wait &” (“wait ampersand”) a useful (bash) shell / shell script idiom or technique

bashshellshell-builtinshell-script

I've "inherited" some shell scripts for Linux machines running the GNU "bash" shell. In one particular case, the machine runs GNU bash version 2.0.5b

One of those scripts has a wait & ("wait ampersand") instruction as part of the "for line" of a for loop. At first sight, that seems to be a curious/interesting idiom, but my web searches for it did not return anything relevant. man wait shows the "BASH_BUILTINS" ("BASH BUILTINS COMMAND") manpage, which has the following description:

wait [n]  
  Wait for the specified process and return its termination status.
  n may be a process ID or a job specification;  if  a  job spec is given,
  all processes in that job's pipeline are waited for.  If n is not
  given, all currently active child processes are waited for, and the 
  return status is zero. If n specifies a non-existent process or job, 
  the return status is 127.  Otherwise, the return status is the exit 
  status of the last process or job waited for.

By reading that part of this manpage, it seems to me that wait & is silently (in the background) making sure that "all currently active child processes are waited for, and the return status is zero.". Am I right in this interpretation? Is this a common and/or useful idiom?

For added context, I'm talking about the following kind of usage in the script:

for file in `ls *.txt ; wait &`
do
   ...
   [cp instructions]
   ...
   [mv instructions]
   ...
   [mailx instruction]
done

Best Answer

I can't imagine any reason to write this code, and I'm not quite sure what the person who wrote this code was trying to achieve. wait here does nothing -- from its perspective, there are no child processes, so it will just exit immediately and basically act as a noop (wait itself executes in a child process due to command substitution, but that's unrelated).

As an aside, parsing the output of ls is quite fragile. Instead, consider just doing this:

for file in *.txt; do
    ...
done

4.3

bash-4.3$ (echo "$BASHPID"; exit 123)
5358
bash-4.3$ wait 5358; echo "$?"
123

4.4

bash-4.4$ (echo "$BASHPID"; exit 123)
12171
bash-4.4$ wait 12171
bash: wait: pid 12171 is not a child of this shell

You can no longer use wait to get the exit status of that subshell that run in foreground (synchronously). foreground refers to jobs of interactive shells, but the same applies for commands run in non-interactive shells.

Note that it also applies to background jobs that are later put in foreground with fg:

bash-4.4$ (sleep 10; exit 123) &
[1] 12857
bash-4.4$ fg
( sleep 10; exit 123 )
bash-4.4$ wait 12857
bash: wait: pid 12857 is not a child of this shell

With bash-4.3 and before bash would remember the exit status of every past background and foreground command. That would not be useful for foreground commands as usually, you don't know their pid in the script and also in things like:

cmd1 &
...
cmd2
wait "$!"

cmd1's pid could very well have been reused for cmd2. In that case wait "$!" would get you the exit status of cmd2 instead of cmd1. Recording the pid of only asynchronous commands slightly reduces the risk of wait giving you the exit status of the wrong command (beside the performance issue mentioned by @Christopher).

Shell – bash script executed over ssh returns incorrect exit code 0

I am able to duplicate this using the command you used, and I am able to resolve it by wrapping the remote command in quotes. Here are my test cases:

#!/bin/bash -x

echo 'Unquoted Test:'
ssh evil sh -x -c exit 5 && echo OK || echo FAIL

echo 'Quoted Test 1:'
ssh evil sh -x -c 'exit 5' && echo OK || echo FAIL

echo 'Quoted Test 2:'
ssh evil 'sh -x -c "exit 5"' && echo OK || echo FAIL

Here are the results:

bash-[540]$ bash -x test.sh
+ echo 'Unquoted Test:'
Unquoted Test:
+ ssh evil sh -x -c exit 5
+ exit
+ echo OK
OK
+ echo 'Quoted Test 1:'
Quoted Test 1:
+ ssh evil sh -x -c 'exit 5'
+ exit
+ echo OK
OK
+ echo 'Quoted Test 2:'
Quoted Test 2:
+ ssh evil 'sh -x -c "exit 5"'
+ exit 5
+ echo FAIL
FAIL

In the first test and second tests, it seems the 5 is not being passed to exit as we would expect it to be. It just seems to be disappearing. It's not going to exit, sh isn't complaining about 5: command not found, and ssh isn't complaining about it.

In the third test, exit 5 is quoted within the larger command to run on the remote host, same as in the second test. This ensures that the 5 is passed to exit, and both are executed as the -c option to sh. The difference between the second and third tests is that the whole set of commands and arguments is sent to the remote host quoted as a single command argument to ssh.

Best Answer

Related Solutions

Bash – Would someone provide an example of a Bash synchronous vs asynchronous job

4.3

4.4

Shell – bash script executed over ssh returns incorrect exit code 0

Related Question