1wait(1) User Commands wait(1)
2
3
4
6 wait - await process completion
7
9 /bin/sh
10 wait [pid]...
11
12
13 /bin/jsh /bin/ksh /usr/xpg4/bin/sh
14 wait [pid]...
15
16
17 wait [% jobid...]
18
19
20 /bin/csh
21 wait
22
23
24 ksh93
25 wait [job...]
26
27
29 The shell itself executes wait, without creating a new process. If you
30 get the error message cannot fork,too many processes, try using the
31 wait command to clean up your background processes. If this doesn't
32 help, the system process table is probably full or you have too many
33 active foreground processes. There is a limit to the number of process
34 IDs associated with your login, and to the number the system can keep
35 track of.
36
37
38 Not all the processes of a pipeline with three or more stages are chil‐
39 dren of the shell, and thus cannot be waited for.
40
41 /bin/sh, /bin/jsh
42 Wait for your background process whose process ID is pid and report its
43 termination status. If pid is omitted, all your shell's currently
44 active background processes are waited for and the return code is 0.
45 The wait utility accepts a job identifier, when Job Control is enabled
46 (jsh), and the argument, jobid, is preceded by a percent sign (%).
47
48
49 If pid is not an active process ID, the wait utility returns immedi‐
50 ately and the return code is 0.
51
52 csh
53 Wait for your background processes.
54
55 ksh
56 When an asynchronous list is started by the shell, the process ID of
57 the last command in each element of the asynchronous list becomes known
58 in the current shell execution environment.
59
60
61 If the wait utility is invoked with no operands, it waits until all
62 process IDs known to the invoking shell have terminated and exit with
63 an exit status of 0.
64
65
66 If one or more pid or jobid operands are specified that represent known
67 process IDs (or jobids), the wait utility waits until all of them have
68 terminated. If one or more pid or jobid operands are specified that
69 represent unknown process IDs (or jobids), wait treats them as if they
70 were known process IDs (or jobids) that exited with exit status 127.
71 The exit status returned by the wait utility is the exit status of the
72 process requested by the last pid or jobid operand.
73
74
75 The known process IDs are applicable only for invocations of wait in
76 the current shell execution environment.
77
78 ksh93
79 wait with no operands, waits until all jobs known to the invoking shell
80 have terminated. If one or more job operands are specified, wait waits
81 until all of them have completed. Each job can be specified as one of
82 the following:
83
84 number number refers to a process ID.
85
86
87 -number number refers to a process group ID.
88
89
90 %number number refers to a job number
91
92
93 %string Refers to a job whose name begins with string
94
95
96 %?string Refers to a job whose name contains string
97
98
99 %+ Refers to the current job
100 %%
101
102 %- Refers to the previous job
103
104
105
106 If one ore more job operands is a process id or process group id not
107 known by the current shell environment, wait treats each of them as if
108 it were a process that exited with status 127.
109
111 The following operands are supported:
112
113 pid The unsigned decimal integer process ID of a command, for
114 which the utility is to wait for the termination.
115
116
117 jobid A job control job ID that identifies a background process
118 group to be waited for. The job control job ID notation is
119 applicable only for invocations of wait in the current shell
120 execution environment, and only on systems supporting the job
121 control option.
122
123
125 On most implementations, wait is a shell built-in. If it is called in a
126 subshell or separate utility execution environment, such as one of the
127 following,
128
129 (wait)
130 nohup wait ...
131 find . -exec wait ... \;
132
133
134
135
136 it returns immediately because there is no known process IDs to wait
137 for in those environments.
138
140 Example 1 Using A Script To Identify The Termination Signal
141
142
143 Although the exact value used when a process is terminated by a signal
144 is unspecified, if it is known that a signal terminated a process, a
145 script can still reliably figure out which signal is using kill, as
146 shown by the following (/bin/ksh and /usr/xpg4/bin/sh):
147
148
149 sleep 1000&
150 pid=$!
151 kill -kill $pid
152 wait $pid
153 echo $pid was terminated by a SIG$(kill -l $(($?−128))) signal.
154
155
156
157 Example 2 Returning The Exit Status Of A Process
158
159
160 If the following sequence of commands is run in less than 31 seconds
161 (/bin/ksh and /usr/xpg4/bin/sh):
162
163
164 sleep 257 | sleep 31 &
165
166 jobs -l %%
167
168
169
170
171 then either of the following commands returns the exit status of the
172 second sleep in the pipeline:
173
174
175 wait <pid of sleep 31>
176 wait %%
177
178
179
181 See environ(5) for descriptions of the following environment variables
182 that affect the execution of wait: LANG, LC_ALL, LC_CTYPE, LC_MESSAGES,
183 and NLSPATH.
184
186 ksh93
187 The following exit values are returned by the wait built-in in ksh93:
188
189 0 wait was invoked with no operands. All processes known by the
190 invoking process have terminated.
191
192
193 127 job is a process id or process group id that is unknown to the
194 current shell environment.
195
196
198 See attributes(5) for descriptions of the following attributes:
199
200
201
202
203 ┌─────────────────────────────┬─────────────────────────────┐
204 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
205 ├─────────────────────────────┼─────────────────────────────┤
206 │Availability │SUNWcsu │
207 ├─────────────────────────────┼─────────────────────────────┤
208 │Interface Stability │Committed │
209 ├─────────────────────────────┼─────────────────────────────┤
210 │Standard │See standards(5). │
211 └─────────────────────────────┴─────────────────────────────┘
212
214 csh(1), jobs(1), ksh(1), ksh93(1), sh(1), attributes(5), environ(5),
215 standards(5)
216
217
218
219SunOS 5.11 13 Mar 2008 wait(1)