In article <20439.1508323...@andromeda.noi.kre.to>, Robert Elz <k...@munnari.oz.au> wrote: > > wait [-n] [-p var] [job ...] > > Wait for the specified jobs to complete and return the exit status > of the last job to exit, or 127 if none of the jobs are a current > child of the shell. > > If no jobs argument is given, wait for all jobs to complete and > then return an exit status of zero (including when there were no > jobs, and so nothing exited.) > > With the -n option, wait instead for any one of the given jobs, or > if none are given, any job, to complete, and return the exit > status of that job. If none of the given job arguments is a > current child of the shell, or if no job arguments are given and > the shell has no unwaited for children, then the exit status will > be 127. > > The -p var option allows the process (or job) identifier of the > job for which the exit status is returned to be obtained. The > variable named (which must not be readonly) will be unset > initially, and then set to the identifier from the arg list (if > given) of the job that exited, or the process identifier of the > job to exit when used with -n and no job arguments. Note that -p > with neither -n nor job arguments is useless, as in that case no > job status is returned, the variable named is simply unset. > > If the wait is interrupted by a signal, its exit status will be > greater than 128. > > Once waited upon, by specific process number or job-id, or by a > wait with no arguments, knowledge of the child is removed from the > system, and it cannot be waited upon again. >
I like the proposal, let's not add any more flags though at this point until we have a use case (-w -u etc.) They will be easy to add later. christos
