On Thu, Oct 17, 2024 at 6:14 PM Chet Ramey <chet.ra...@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.ra...@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.
