Date: Thu, 2 May 2024 12:17:36 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <b170e2e7-47aa-4e27-a4c2-d14759dad...@case.edu>
| It's the reporting part we're talking about here, not the removing.
Should be effectively the same thing for the jobs in question (which
aren't ones that are stopping) - when a terminated job is reported, it
gets removed (or should).
| It's a jobs list.
In posix it is a background jobs list - there's no expectation that
foreground jobs go anywhere near it.
| Things hang around in there until the user gets notified,
| whether before the next interactive shell prompt, as POSIX specifies,
Yes, or immediately with set -b (which the NetBSD sh might implement
one day soon!)
| or before the next command is executed in a non-interactive shell.
That's a bash invention. In the pure POSIX environment, nothing ever
runs the jobs command in a non-interactive shell, unless the script
does it explicitly. I'm not 100% sure that the standard is really
very precise about what happens when -m is enabled in a non-interactive
shell, or that anyone really considered what current shells do, or
should do (but that isn't in any way related to anything currently
under discussion.)
| Everyone reports on foreground job termination before the next
| command in a list.
Yes. But that's an entirely different thing in POSIX.
Remember the history, jobs lists (and set -m, and everything related)
were not part of the original standard. What was left (foreground and
async processes) was defined how to function with no mention of jobs
lists, or jobs commands, or anything similar. Then the jobs stuff was
grafted in, first as an optional extra, then mandatory (since everyone,
that matters anyway, does it.) It can hardly be a surprise that there
might be a few rough edges around the merge sites.
| The question is whether you do it before word expansion or after.
Sorry, that distinction makes no sense to me at all. Once you start
on word expansions, you're processing the next command - during that
period (the possible handling of set -b via SIGCHLD excepted, and I'm
not sure even that should be done at this time) you should just be
processing that, that's the common shell behaviour, nothing goes to wait
for possible exiting processes until the new process is ready to be waited
for (or a new prompt is to be issued if the process was async).
Given that the original shells just had wait(2) to work with, none
of the later additions, this shouldn't be a big surprise.
| But I think we're getting to agreement here.
Yes, but I never really though there was any reason for any disagreement.
kre
