Chet Ramey wrote, on 11 May 2022:
>
> On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group wrote:
> 
> >> 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.
> 
> 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.

You're looking in (some of) the right places, but missing the
significance of what's written there.  For example, on the jobs page
it says in STDOUT that the job number written to standard output
is "A number that can be used to identify the process group to the
wait, fg, bg, and kill utilities."

Since it identifies a process *group*, it's not possible for a job
number to identify an asynchronous command that was started with
job control disabled (as it won't be run in its own process group).

This is confirmed by the OPERANDS sections for kill and wait, which
describe the second form for the pid operand as "A job control job ID
(see XBD Section 3.204, on page 66) that identifies a background
process group to be {signaled/waited for}."

Also, you mention "the definition of Job ID", but there is no such
definition. The term that is defined is "Job Control Job ID", which
implies that a "Job ID" is always something connected with job control.

> >> 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.
> 
> So for the known IDs list, it's pretty much `wait' and `jobs', right?

The phrase kre used was "when their termination status has been
reported to the user - however that happens".  That includes information
written by an interactive shell before it writes a prompt.  Although
the standard says this information is about the exit status of
"the background job", it is also, by association, information about
the exit status of a process in the known process IDs list.

-- 
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

      • Re: When ca... Chet Ramey via austin-group-l at The Open Group
        • wait an... Geoff Clare via austin-group-l at The Open Group
          • Re:... Chet Ramey via austin-group-l at The Open Group
          • Re:... Robert Elz via austin-group-l at The Open Group
            • ... Chet Ramey via austin-group-l at The Open Group
      • Re: When ca... Geoff Clare via austin-group-l at The Open Group
        • Re: Whe... Chet Ramey via austin-group-l at The Open Group
          • Re:... Geoff Clare via austin-group-l at The Open Group
            • ... Chet Ramey via austin-group-l at The Open Group
              • ... Steffen Nurpmeso via austin-group-l at The Open Group
              • ... Geoff Clare via austin-group-l at The Open Group
              • ... Chet Ramey via austin-group-l at The Open Group
        • Re: Whe... Chet Ramey via austin-group-l at The Open Group
        • Re: Whe... Robert Elz via austin-group-l at The Open Group
          • Re:... Chet Ramey via austin-group-l at The Open Group
          • Re:... Robert Elz via austin-group-l at The Open Group
        • Re: Whe... Robert Elz via austin-group-l at The Open Group
          • Re:... Chet Ramey via austin-group-l at The Open Group
    • Re: When can sh... Chet Ramey via austin-group-l at The Open Group
  • Re: When can shells ... Chet Ramey via austin-group-l at The Open Group

Reply via email to