Chet Ramey wrote, on 06 May 2022:
>
> 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.
If it works with "wait" in all shells (that we care about), then I
agree it would make sense to add it.
> > 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.
The changes I've already worked on for bug 1254 add a lot of job control
detail in a new "Job Control" section in XCU chapter 2.
> > 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.
The normative text relating to creation of job numbers/IDs is all
conditional on job control being enabled.
When the "jobs" rationale says:
... 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.
it seems to me that "background jobs associated with that current session"
is referring to jobs that were created before the "set +m".
> > > 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.
I think kre intended it apply to the known IDs list as well, and I
was agreeing with that.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
