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

[Zachary Santer]

On Mon, Sep 9, 2024 at 9:06 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 9/8/24 11:13 PM, Oğuz wrote:
> > On Monday, September 9, 2024, Zachary Santer <zsanter@gmail.com
> > <mailto:zsanter@gmail.com>> wrote:
> >
> >     Slightly improved wait-n-failure attached.
> >
> >
> > It's >100 lines and your replies are too long. Summarize what you want so
> > others can contribute too without having to waste time reading the whole
> > thread.
>
> 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:

A) Solve 'wait -n' inconsistency through changes to job status notification:
- 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

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
- '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

A) and B) could both cause problems for backwards compatibility.

B) is my preference.

wait-n-failure demonstrates bash's (mis)behavior in various
configurations in a way that's fairly simple for the user to test and
see for themselves. I'd argue the implementation isn't particularly
important unless you want to check my work.