STANDARD INPUT

None.

INPUT FILES

None.

ENVIRONMENT VARIABLES

The following environment variables shall affect the execution of wait:

LANG

This variable shall determine the locale to use for the locale categories when both LC_ALL and the corresponding environment variable (beginning with LC_ ) do not specify a locale. See 2.6.

LC_ALL

This variable shall determine the locale to be used to override any values for locale categories specified by the settings of LANG or any environment variables beginning with LC_.

LC_CTYPE

This variable shall determine the locale for the interpretation of sequences of bytes of text data as characters (e.g., single- versus multibyte characters in arguments).

LC_MESSAGES

This variable shall determine the language in which messages should be written.

ASYNCHRONOUS EVENTS

Default.

STANDARD OUTPUT

None.

STANDARD ERROR

Used only for diagnostic messages.

OUTPUT FILES

None.

EXAMPLES

On most implementations, wait is a shell built-in. If it is called in a subshell or separate utility execution environment, such as one of the following:

( wait ) nohup wait ... find . -exec wait ... \;

it will return immediately because there will be no known process IDs to wait for in those environments.

Although the exact value used when a process is terminated by a signal is unspecified, if it is known that a signal terminated a process, a script can still reliably figure out which signal using kill as shown by the following script: sleep 1000& pid=$! kill -kill $pid wait $pid echo $pid was terminated by a SIG $(kill -l $?) signal. Historical implementations of interactive shells have discarded the exit status of terminated background processes before each shell prompt. Therefore, the status of background processes was usually lost unless it terminated while wait was waiting for it. This could be a serious problem when a job that was expected to run for a long time actually terminated quickly with a syntax or initialization error because the exit status returned was usually zero if the requested process ID was not found. POSIX. 2 requires the implementation to keep the status of terminated jobs available until the status is requested, so that scripts like: j1& p1=$! j2& wait $p1 echo Job 1 exited with status $? wait $! echo Job 2 exited with status $? will work without losing status on any of the jobs. The shell is allowed to discard the status of any process that it determines the application cannot get the process ID from the shell. It is also required to remember only CHILD_MAX number of processes in this way. Since the only way to get the process ID from the shell is by using the ! shell parameter, the shell is allowed to discard the status of an asynchronous list if $! was not referenced before another asynchronous list was started. (This means that the shell only has to keep the status of the last asynchronous list started if the application did not reference $!. If the implementation of the shell is smart enough to determine that a reference to $! was not ‘‘saved’’ anywhere that the application can retrieve it later, it can use this information to trim the list of saved information. Note also that a successful call to wait with no operands discards the exit status of all asynchronous lists.)

This new functionality was added because it is needed to accurately determine the exit status of any asynchronous list. The only compatibility problem that this change creates is for a script like: while sleep 60 do job& echo Job started $(date) as $! done which will cause the shell to keep track of all of the jobs started until the script terminates or runs out of memory. This would not be a problem if the loop did not reference $! or if the script would occasionally wait for jobs it started. If the exit status of wait is greater than 128, there is no way for the application to know if the waited for process exited with that value or was killed by a signal. Since most utilities exit with small values, there is seldom any ambiguity. Even in the ambiguous cases, most applications just need to know that the asynchronous job failed; it does not matter whether it detected an error and failed or was killed and did not complete its job normally.

HISTORY OF DECISIONS MADE

The description of wait does not refer to the waitpid() function from POSIX. 1 {8}, because that would needlessly overspecify this interface. However, the wording requires that wait is required to wait for an explicit process when it is given an argument, so that the status information of other processes is not consumed. Historical implementations use POSIX. 1 {8} wait until wait returns the requested process ID or finds that the requested process does not exist. Because this means that a shell script could not reliably get the status of all background children if a second background job was ever started before the first job finished, it is recommended that the wait utility use a method such as the functionality provided by the waitpid() function in POSIX. 1 {8}. The ability to wait for multiple pid operands was adopted from the KornShell at the request of ballot comments and objections. Some implementations of wait support waiting for asynchronous lists identified by the use of job identifiers. For example, wait %1 would wait for the first background job. This standard does not address job control issues, but allows these features to be added as extensions. Job control facilities will be provided by the UPE.