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

[Zachary Santer]

On Thu, Oct 17, 2024 at 6:14 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 9/29/24 12:55 PM, Zachary Santer wrote:
> > On Wed, Sep 25, 2024 at 11:06 AM Chet Ramey <chet.ramey@case.edu> wrote:
> >>
> > I might argue that calling 'jobs' within a script being executed
> > normally shouldn't make background jobs that have already terminated
> > unavailable to 'wait -n' either.
>
> Make up your mind. Is non-interactive shell behavior good, as you've said
> before, and again at the end of this message, or is it not?

It's good if you don't call 'jobs'. All I was saying is that my most
probable use case for 'wait -n' is fine. I don't see myself calling
'jobs' from within a script.

> > I might be missing something, but bash sure seems to be doing this in
> > a number of different calls to wait-n-failure::main, on the current
> > devel branch commit. Are the jobs not being removed from the jobs
> > table until some later point?
>
> What? When jobs are added to the jobs list, they use the index after
> the largest index with a job. If you have four jobs, 1-4, and job 3
> terminates, the next job created gets index 5. If job 4 terminates
> instead, the next job created gets index 4. Is this not what you're
> seeing?

Yeah it is. So I was missing something.

> >> So you are saying that prompt notifications and `jobs' have the same
> >> effect. POSIX implies but does not require this, and there is differing
> >> behavior among current implementatations.
> >
> > I've got no opinion on this point, actually.
>
> You just described it. Are you saying you don't mind either behavior?

Yeah, I thought I was saying this bit of existing behavior would
remain unchanged. I wasn't correctly describing the existing behavior,
though, so nevermind.

> >> This is posix mode.
> >
> > How does the user know that?
>
> How does a user know anything? What's the difference between "documented
> in the man page" (presumably in JOB CONTROL or the `wait' description?)
> and "documented as part of posix mode"?

That's fair.

> > And now I know that, but I don't even use 'wait -n' for anything.
>
> Then we're just having an academic conversation.

Yeah, I dragged myself into this from the procsub wait discussion.
Nobody else really spoke up. Hopefully, this has been useful.

> > The point here was to try to get the behavior of 'wait -n' to be as
> > consistent as possible, between different execution environments: the
> > interactive shell, a script being sourced, and a script being executed
> > normally; along with different set and shopt options. If you won't
> > consider modifying the behavior of 'wait -n' without id arguments in
> > default mode, then that's frustrating.
>
> You might want to try posix mode for a while and see what happens. There
> are very few people who do that; I'd be interested in feedback.

I can work around function names needing to be valid shell 'name's by
simply waiting to do 'set -o posix' after all the functions are
defined, but items 8 and 58 in the POSIX file are a couple of
head-scratchers.

On item 58:
My external 'kill' is from Cygwin Utilities, naturally, but its -l
does what bash's 'kill -l' does in POSIX mode and its -L does
something similar to what bash's 'kill -l' does in default mode. Could
POSIX-mode bash 'kill -L' still give the table, instead of doing the
same thing as 'kill -l'?

Item 8 is just odd and is on the verge of being a dealbreaker. Not to
go off on another tangent, but what on Earth?

Item 3 is also a weird thing to do, but you can turn alias expansion
right back off in a script with 'shopt -u expand_aliases', so
whatever.

I notice that I don't have to do
  set -o posix
  wait
  set +o posix
if I want to keep POSIX mode restricted to just the behavior of 'wait'.

This works
  POSIXLY_CORRECT='y' wait
so that's cool.