Re: 'wait -n' with and without id arguments

[Chet Ramey]

On 9/9/24 10:45 AM, Zachary Santer wrote:

> > He wants interactive shells to notify the user less frequently about job
> > status changes so `wait -n' works better.
>
> That's one option, but not my preferred option. I'll attempt a tl;dr:

Stipulating that this is for interactive shells only.

> A) Solve 'wait -n' inconsistency through changes to job status notification:

Pretty non-specific, but I assume you want notifications to behave like
POSIX specifies in the latest version of the standard.

> - Would require more user-facing changes to bash's behavior in default mode
> - Potentially more difficult to implement correctly
> - Would leave some loose ends that would just have to be documented in
> the man page

Like `set -b'?

> B) Solve 'wait -n' inconsistency by allowing it to act on the list of
> saved pids and statuses of jobs whose termination has already been
> notified to the user:
> - POSIX doesn't agree with the existence of that list

POSIX says everything should disappear when you get notified or the
subject of `wait', so there's that (bash just does it on `wait'). Those
semantics have defenders just as ardent as you are.

> - 'set -o posix' exists so bash's default behavior can differ from
> that specified by POSIX when POSIX is wrong-headed
> - now I think 'wait' with id arguments should clear those ids and
> statuses from the list of notified jobs, which does increase the
> user-facing changed behavior a bit

That's more POSIX semantics, and it's already implemented in posix mode.
You have to do that anyway, to avoid handing back the same pid repeatedly
when `wait -n' is called.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/