On 28/02/2022 23:20, Robert Elz via austin-group-l at The Open Group wrote:
It is worth pointing out though that testing this in interactive shells
is somewhat of a weird case - it should probably be done in a script
instead. That's because of the effect of the (implicit) jobs command
before
Date:Mon, 28 Feb 2022 20:47:47 -0800
From:Don Cragun
Message-ID:
| The requirement for the shell to keep the exit status for a known
| terminated process until wait is called is in [...]
Thanks, but I knew all of that, and we do all of that.
There's also (from
o
> point since it doesn't work, issuing wait commands for known already completed
> background jobs ... they already no longer exist). How all this interacts
> with stopped jobs and wait(1) (as distinct from waitpid(2) (or (3)) seems
> to be wholly unspecified - hence running these
or known already completed
background jobs ... they already no longer exist). How all this interacts
with stopped jobs and wait(1) (as distinct from waitpid(2) (or (3)) seems
to be wholly unspecified - hence running these tests in a script, where
there's no PS1 and hence no implicit jobs command is
< said:
> Hi,
> wait is specified as:
>If one or more pid operands are specified that represent known process
>IDs, the wait utility shall wait until all of them have terminated.
> In no shell does the wait utility appear to behave this way. To test
> this, in an interactive shell, I
Hi,
wait is specified as:
If one or more pid operands are specified that represent known process
IDs, the wait utility shall wait until all of them have terminated.
In no shell does the wait utility appear to behave this way. To test
this, in an interactive shell, I tried:
sleep 10 &
