Date: Tue, 30 Apr 2024 10:29:43 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <958687ce-7e36-42d1-a82e-6101fc777...@case.edu>
| That's an interpretation. I might buy it if the DESCRIPTION didn't say
|
| "When jobs reports the termination status of a job, the shell shall remove
| the job from the background jobs list ..."
|
| which implies that it's `jobs' doing the reporting.
No, it implies nothing of the kind. It says what happens when jobs
reports the termination status, it doesn't say, or imply, that the
thing that happens (removing the job) only happens when the jobs command
is run, which would imply that it needs to be.
But beyond that, ask yourself, what is a foreground job doing on the
background jobs list?
I know (because we do it too) that it is convenient (vastly simpler
code) to just stick everything in a jobs list, not distinguishing
background and foreground jobs (or not by what list they're on).
But POSIX (mostly anyway, and certainly here) is documenting what
shells do, and no shell I know of ever reports status of any
foreground job using the jobs command. Other than what has been
reported here, bash certainly doesn't, not even for processes
which are terminated by signals. Just run "sleep 1000" then send
a SIGQUIT (^\ usually) and look at the output ... nothing like
the format required of the jobs command (and nor does it need to be).
Of course, since these new non subshell command substitutions are
not in POSIX at all, they're a bash invention, you can invent your
own rules for how they are reported, or how processes in them are
reported, but that should at least be a consistent set of rules.
And you cannot rely on anything POSIX says to justify any new
invention you come up with.
| That appears in a few other places:
Sure, and they're also all saying the same thing.
| That's where I'm going with this: trying to figure out a general rule that
| everyone can agree on for which jobs `jobs' should *not* report on,
Simple - foreground jobs. Any and all of them (including ones which
once were background jobs, but have been fg'd.
Those plus any async (bg) jobs which have already been waited upon explicitly.
| (like it would if the job were terminated by a signal).
No it doesn't. See above.
| (for various reasons, you don't want the jobs list to change during
| nofork comsubs).
I have no knowledge of the internals of bash, or why it is doing what
it is doing, but that seems likely to be an impossible requirement to
meet. How about when one of those starts an async command? The jobs
list needs to have that job added to it (and there might be many of them).
And what of when the jobs command is run inside one of these things?
The jobs it reports on as done need to be removed. And if both of those
happen in the same nofork comsub (if that's what they are being called),
then the jobs command needs to find the async processes started earlier,
if they have completed, not just earlier ones.
Or it least externally, those things need to appear to have happened,
you can implement it all however you like, using temporary jobs lists
while the nofork comsub is running, if that is what is needed, but none
of that should make any difference to how it all appears to a user or
script.
kre
