On Mon, Sep 9, 2024 at 9:06 AM Chet Ramey <chet.ra...@case.edu> wrote: > > On 9/8/24 11:13 PM, Oğuz wrote: > > On Monday, September 9, 2024, Zachary Santer <zsan...@gmail.com > > <mailto:zsan...@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.
