On 5/11/22 6:31 PM, Robert Elz wrote:
| For neither the first nor the last time.
Including now.
People can disagree.
| > I think they should remain independent.
| Sure, I agree.
I don't. I cannot think of a single reason why the shell should be
forced to maintain two separate lists of its child processes. The jobs
table needs to have them, so processes in the job can be identified as
they finish. Duplicating that in another table, for no particular reason
I can imagine makes no sense to me. Still, if others want to implement
it that way, I don't object - but the standard has never required that,
and should not, absent some very good reason, be changed to require it now.
It's going to take more work on the standard to make it be that way, then.
There will have to be more specific language about when and how the jobs
list is created, when jobs are added and removed, when and how jobs
correspond to known process IDs, and whether or not removing IDs from that
list just means removing the job from the table. If we're going to require
job control to be enabled to maintain a jobs list, at least a visible one,
then we have to have something else to use. It may be the jobs list
internally, if we end up fixing all the places in the standard that are
underspecified, and that would probably work.
It's my impression that the known IDs list is a remnant from the time when
job control was optional, and you didn't need to implement job control
unless you implemented the UPE. You still needed a way to keep track of
background processes, and the known IDs list was it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
