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

[#!microsuxx]

is there plans to add / handle multiple redirection-procs in one cmd in the
jobs table

On Thu, Oct 17, 2024, 23:15 Chet Ramey <chet.ramey@case.edu> wrote:

> On 9/22/24 1:48 PM, Zachary Santer wrote:
> > If you're not going to make 'wait -n' without id
> > arguments pull something from the bgp list, then the 'set -o posix'
> > notification behavior ought to be made the default behavior, yeah.
>
> I think keeping posix mode behavior is fine.
>
> >> Like `set -b'?
> >
> > Yeah, that really needs to be mentioned explicitly.
>
> The job control section already mentions notify, and the latest (heavily
> edited) versions mention that jobs are removed from the jobs table when
> the user is notified.
>
>
> > If the default
> > notification behavior stays as is, it should also mention that 'wait
> > -n' without id arguments in the interactive shell, with 'set -m'
> > enabled, requires that 'set -o posix' be enabled as well, for reliable
> > I could see putting all that in the BUGS section.
> >
>
> It's not a bug. I mean, I know there's some stuff in the BUGS section
> that's not a bug that's been there for a while, but this isn't a bug.
> It's just how notify works.
>
> > I know I never looked at it before I got burnt the first time.
>
> Apparently.
>
> >
> >>> 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.
> >
> > Maybe those defenders can elucidate what purpose that behavior would
> serve.
>
> kre's on the list, maybe he'll speak up. I'm not going to speak for him.
> He's written about this before.
>
> https://lists.gnu.org/archive/html/bug-bash/2024-08/msg00124.html
> https://lists.gnu.org/archive/html/bug-bash/2024-08/msg00179.html
>
> > At the end of the day, B) is by far the simpler solution, and wouldn't
> > leave a bunch of configurations where 'wait -n' doesn't really work
> > quite right in the interactive shell.
>
> It will work that way in posix mode for now.
>
> --
> ``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/
>