On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The fact that the jobs command works with job control disabled is
mentioned in the rationale on the jobs page:
The jobs utility is not dependent on the job control option, as
are the seemingly related bg and fg utilities because jobs is
useful for examining background jobs, regardless of the condition
of job control. When the user has invoked a set +m command and job
control has been turned off, jobs can still be used to examine the
background jobs associated with that current session. Similarly,
kill can then be used to kill background jobs with kill
%<background job number>.
so that's not an "issue".
If jobs and kill work, you should probably add wait to this description, or
add a separate paragraph to the wait rationale.
XBD 2.175 defines a job as
A set of processes, comprising a shell pipeline, and any
processes descended from it, that are all in the same process group.
Which says nothing very useful, and I am not sure is even correct.
Yes, I made the same point in a previous message.
The reason I think #2 should say "if job control is disabled" is
because the standard talks separately about the list of "process IDs
known in the shell environment" and the job list / job IDs.
I think it needs to talk a little bit more clearly about the jobs list and
what constitutes a job, not to mention how and when one gets created.
Anyway, this also implies the existence of two separate lists.
Your testing above seems to be conflating the "known IDs" and the jobs
list. My reading of the standard is that entries in the jobs list only
need to be created when job control is enabled,
I'd be interested in your reasoning. The standard simply says that jobs
and kill (and wait should be added) work with job %X notation whether
or not job control is enabled. And in any event, that's not how shells
work.
I do agree that the current text implies two separate lists, and there's
insufficient explanation of how they interact. It certainly doesn't imply
that the `known IDs' stuff is only in effect when job control is not
enabled.
Independently of this, when
job control is disabled all of the requirements relating to "known IDs"
still apply and have nothing to do with %... job ID notation.
If you make that change. The known IDs description doesn't depend on job
control being enabled or disabled.
| I think the description of the wait utility should be updated to require
| removal from the list.
I would agree with that.
I wouldn't object.
If someone wants to implement it that way, I have no objection, but it
should not be required. shells should at least be permitted to remove
jobs from the list of remembered stuff when their termination status has
been reported to the user - however that happens.
I agree.
OK. I'm pretty sure everyone already does this for the jobs list. Not sure
whether you want it to include the known IDs list.
That could be another valid choice, but I would prefer that all shells
wait for termination by default.
You might, but that's not the current state of the world.
--
``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/
