How To Wait To Finish Background Job In Shell Script

14.1. Job Control Commands

Sure of the following job control commands take a "job identifier" as an argument. Encounter the tabular array at end of the affiliate.

jobs

Lists the jobs running in the background, giving the task number. Not as useful equally ps.

It is all too easy to confuse jobs and processes. Certain builtins, such as kill, disown, and wait take either a task number or a procedure number every bit an argument. The fg, bg and jobs commands accept only a job number.

                                fustigate$                                                                                                  sleep 100 &                                                                [one] 1384                                bash $                                                                                                  jobs                                                                [1]+  Running                 sleep 100 &

"1" is the chore number (jobs are maintained by the current crush). "1384" is the PID or process ID number (processes are maintained by the arrangement). To kill this job/procedure, either a impale %one or a kill 1384 works.

Cheers, Due south.C.

disown

Remove job(s) from the shell's table of active jobs.

fg, bg

The fg control switches a task running in the background into the foreground. The bg command restarts a suspended job, and runs it in the background. If no job number is specified, so the fg or bg command acts upon the currently running job.

wait

Suspend script execution until all jobs running in groundwork have terminated, or until the job number or procedure ID specified as an option terminates. Returns the leave status of waited-for command.

You may use the look control to prevent a script from exiting before a background chore finishes executing (this would create a dreaded orphan process).

Case 14-26. Waiting for a process to stop before proceeding

#!/bin/bash  ROOT_UID=0   # Merely users with $UID 0 have root privileges. E_NOTROOT=65 E_NOPARAMS=66  if [ "$UID" -ne "$ROOT_UID" ] then   echo "Must be root to run this script."   # "Run along kid, it's past your bedtime."   exit $E_NOTROOT fi    if [ -z "$1" ] then   echo "Usage: `basename $0` find-cord"   get out $E_NOPARAMS fi   echo "Updating 'locate' database..." echo "This may have a while." updatedb /usr &     # Must be run every bit root.  wait # Don't run the rest of the script until 'updatedb' finished. # You want the the database updated earlier looking up the file name.  locate $ane  #  Without the 'expect' command, in the worse instance scenario, #+ the script would go out while 'updatedb' was however running, #+ leaving it as an orphan process.  get out 0

Optionally, wait can have a task identifier as an argument, for example, wait%1 or wait $PPID . Encounter the job id table.

Within a script, running a command in the groundwork with an ampersand (&) may cause the script to hang until ENTER is hit. This seems to occur with commands that write to stdout. It can be a major annoyance.

#!/bin/bash # exam.sh		    ls -l & repeat "Done."

                                fustigate$                                                                                                  ./exam.sh                                                                Done.  [bozo@localhost test-scripts]$ total 1  -rwxr-xr-x    one bozo     bozo           34 October 11 fifteen:09 test.sh  _

Placing a wait afterwards the background command seems to remedy this.

#!/bin/bash # test.sh		    ls -l & echo "Done." look

                                bash$                                                                                                  ./test.sh                                                                Done.  [bozo@localhost test-scripts]$ total 1  -rwxr-xr-10    1 bozo     bozo           34 October 11 15:09 examination.sh

Redirecting the output of the command to a file or fifty-fifty to /dev/null likewise takes care of this trouble.

suspend

This has a like effect to Control-Z, but it suspends the vanquish (the shell'south parent process should resume it at an appropriate time).

logout

Exit a login trounce, optionally specifying an get out condition.

times

Gives statistics on the system time used in executing commands, in the following form:

This capability is of very limited value, since information technology is uncommon to profile and benchmark shell scripts.

impale

Forcibly terminate a process by sending it an appropriate cease signal (meet Example 16-half-dozen).

Example fourteen-27. A script that kills itself

#!/bin/bash # cocky-destruct.sh  kill $$  # Script kills its own process hither.          # Call up that "$$" is the script's PID.  echo "This line will not repeat." # Instead, the shell sends a "Terminated" bulletin to stdout.  exit 0   # Normal exit? No!  #  Later on this script terminates prematurely, #+ what exit status does it return? # # sh self-destruct.sh # repeat $? # 143 # # 143 = 128 + 15 #             TERM signal

kill -l lists all the signals (equally does the file /usr/include/asm/signal.h). A impale -ix is a sure kill, which will usually terminate a process that stubbornly refuses to die with a plain kill. Sometimes, a kill -15 works. A "zombie" process, that is, a child process that has terminated, but that the parent process has not (however) killed, cannot be killed by a logged-on user -- you can't impale something that is already dead -- simply init will generally clean it up sooner or later.

killall

The killall command kills a running procedure past name, rather than by process ID. If there are multiple instances of a detail command running, then doing a killall on that command will terminate them all.

This refers to the killall control in /usr/bin, not the killall script in /etc/rc.d/init.d.

command

The control directive disables aliases and functions for the command immediately following it.

This is i of 3 beat directives that effect script control processing. The others are builtin and enable.

builtin

Invoking builtin BUILTIN_COMMAND runs the command BUILTIN_COMMAND as a beat builtin, temporarily disabling both functions and external system commands with the same name.

enable

This either enables or disables a shell builtin command. As an case, enable -n kill disables the shell builtin kill, and then that when Bash subsequently encounters kill, information technology invokes the external control /bin/kill.

The -a choice to enable lists all the shell builtins, indicating whether or not they are enabled. The -f filename option lets enable load a builtin as a shared library (DLL) module from a properly compiled object file. [one].

autoload

This is a port to Bash of the ksh autoloader. With autoload in identify, a function with an autoload declaration will load from an external file at its first invocation. [ii] This saves system resources.

Annotation that autoload is not a function of the core Bash installation. It needs to be loaded in with enable -f (encounter higher up).

Table 14-1. Chore identifiers

Note	Meaning
`%N`	Job number [N]
`%S`	Invocation (command line) of task begins with string S
`%?S`	Invocation (command line) of job contains within it string S
`%%`	"current" chore (last job stopped in foreground or started in background)
`%+`	"current" job (final job stopped in foreground or started in background)
`%-`	Last job
`$!`	Final background procedure