[Robert Cc'ed this to austin-grou...@netbsd.org which presumably bounced.
I'm taking that as indication that he intended it to go to this list,
and am quoting it in full.]
Robert Elz wrote, on 12 May 2022:
>
> | The standard needs to specify them separately because, as per the
> | mail I just sent in reply to Chet, job numbers identify process groups
> | and therefore cannot identify asynchronous commands started with job
> | control disabled.
>
> You are over reaching in the way you are reading that text.
I strongly disagree.
> The job notation needs to be able to refer to jobs with
> process groups, and for some shells (incl NetBSD for the
> kill command, currently) but there is nothing preventing
> a shell from extending tge jobs table (and job id notation)
> to cover non job control jobs. And aside from bosh, all
> shells do.
The standard clearly requires that the job number written by "jobs"
identifies a process group. A shell which includes a "job" in
the jobs output that does not have its own process group does not
conform to that requirement.
However, what the standard requires here does not match existing
practice in some shells and so the standard should change.
> | However, it is an internal implementation detail how that is managed.
>
> Agreed, but when one or the other is to be deleted, when those
> are not specified identically, it makes a noticeable difference.
>
> There is also the question of whether a scriot can wait for
> a process that is in an asybc non-trivial pipeline, which is
> not the one which is $!. In the jobs table, all the pids
> need to be maintained (all children of this shell) so the
> parent can associate them with the correct pipeline so
> termination of the job can be determined (not just termination
> of the process which happened to be $! when the pipeline
> started, and so the pipefail option can work correctly
>
> I would prefer if the standard did not require retaining a known
> pid once the jobs entry that contains that pid is stated to
> be removed. Nb: not require retaining, not not permit retaining.
>
> | If you want to have one table with some flag to say whether each
> | entry is a job or a "known process ID that's not a job", that's fine.
>
> There is no such thing as a known process ID that is not a job.
> That is quite clear in the XBD definition of a job.
It's not clear at all, and I would say the opposite is implied.
The definition of "Job" is:
A set of processes, comprising a shell pipeline, and any processes
descended from it, that are all in the same process group.
Notice it says "that are all in the same process group". In the
case of a background command started with job control disabled, the
processes all have the same process group as the parent shell.
By a strict reading, this counts as a job, but I don't think that
was intended.
In any case we already know that the current definition of "job" is
very wrong, so using it to support either position is futile.
> It might not (without an extension to the standard being used)
> be possible to always use the %n (etc) notation to manipulate
> such jobs, but they very clearly are jobs.
>
> Hence no such flag is required. Knowing whether the job was
> started under job control, and hence has a pgrp of its own,
> is required, but that is a different thing entirely.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
