Date: Wed, 11 May 2022 09:17:15 -0400
From: "Chet Ramey via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <573bc015-dd85-f86e-b89d-33a0bcc4b...@case.edu>
Again, apologies, still very little time for any of this.
| For neither the first nor the last time.
Including now.
| > 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.
In a later message Chet said:
| > The normative text relating to creation of job numbers/IDs is all
| > conditional on job control being enabled.
| Where is that? It's not in the definition of Job ID, it's not in 2.9.3
| Asynchronous Lists, it's not in the `jobs' description, it's not part of the
| definition of Background Job or Foreground Job, it's not in any of fg/bg/kill/
| wait. I feel like I'm missing something obvious here.
Again, I disagree. You're missing nothing. There has not been anything
like Geoff is postulating - there might be in his unpublished new draft text,
but there is no reason I can imagine that such a change should be adopted.
kre
