On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
You are over reaching in the way you are reading that text.
I strongly disagree.
If you have to work that hard to make your case, it's a good indication
that the existing language is wrong -- or at least insufficient -- and
needs to be changed.
There is no such thing as a known process ID that is not a job.
Bash allows process substitutions to set $!, so users can wait for them,
but they are not jobs. Process substitution is, of course, an extension.
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.
Why not? This is what allows jobs/kill/wait to use job control notation
in operands even when job control is not currently enabled. I'd argue
that that was intended.
--
``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/
