Robert Elz wrote, on 30 Apr 2022:
>
> | However, today it threw a last curve ball when I was working on an
> | update to the description of set -b ...
>
> How many shells actually implement that?
They all accept it as an option, but for some it seems to be a no-op.
That's one of the changes I was working on when I spotted this problem.
> | This conflicts with 2.9.3.1 Asynchronous Lists which says that IDs
> | remain known until:
> |
> | 1. The command terminates and the application waits for the process ID.
> |
> | 2. Another asynchronous list is invoked before "$!" (corresponding to
> | the previous asynchronous list) is expanded in the current execution
> | environment.
>
> Does anyone implement that bit (#2) at all? In a non-interactive shell it
> might almost be possible, but in an interactive shell, if the job isn't in
> the list (whether $! has been referenced or not - usually it will not have
> been) because it has been removed, what is the shell supposed to do if the
> job stops? Further users (even in scripts) are allowed to use % %- %1
> etc to refer to jobs, $! isn't the only way to reference one ("wait %2 should
> work). I'd suggest that #2 should simply be removed.
I think #2 should say "If job control is disabled, ...".
> But do note that the definition of the jobs command says:
>
> When jobs reports the termination status of a job, the shell shall
> remove its process ID from the list of those ``known in the current
> shell execution environment''; see Section 2.9.3.1 (on page 2338).
>
> (quote from I8 Draft 2.1 -- but that text has been there forever, or
> seemingly).
>
Good catch. That should be added to the numbered list in 2.9.3.1.
> So that's another way that an entry is removed, and this one is "shall remove"
> whereas "remain known until" puts a minimum on how long the job is supposed
> to remain known, but doesn't actually require removal. For #2 that's
> obvious,
> shells aren't required to make that optimisation (that's some academic view of
> what was thought should be possible - but isn't in practice), but for #1 if
> the job isn't removed (when wait happens) then it could still be there, again,
> and again, forever
I think the description of the wait utility should be updated to require
removal from the list.
> | My initial reaction to this was that the above quote from set -b is
> | likely a left-over from before the decision to disallow the historical
> | remove-before-prompting behaviour was made.
>
> I doubt that -b is particularly relevant to this, other than that it provides
> an alternate time at which termination status of a process can be shown.
>
> | However, then I spotted that the text from wait, which seems to be an
> | attempt to justify that decision, first says it was historical
> | behaviour for *interactive* shells but then talks about the problems
> | it could cause for *scripts*. So it seems to me that the
> | justification does not stand up to scrutiny.
>
> The justification doesn't, but for scripts I don't recall there ever
> really being an issue - the removal happens when the status of jobs which
> have changed status is reported just before PS1 is written, and
> non-interactive shells (scripts) don't do that.
>
> On the other hand, users of interactive shells are not in the habit of
> issuing wait commands (even jobs commands, without some reason do do so).
I have done it occasionally, when I have a bunch of background jobs
running and I don't care about their individual status, I just want
to be told when they've all finished:
command1 &
.
.
commandN &
wait; echo ALL DONE
However, in this particular scenario it wouldn't matter if command1, say,
had already finished and been removed from the list when I typed the wait
command.
> They expect to be told when a background job has finished (without -b both
> working, and set, that might require causing new prompts to appear from time
> to time) and simply expect that when a job has been reported as done, it is
> done, and no longer exists.
>
> | It also appears that dash still implements remove-before-prompting.
>
> Does anyone not?
Most shells do not. Harald's reply has the details.
> | B. Allow remove-before-prompting. This would mean changing 2.9.3.1 to
> | add a third list item (for interactive shells only) and deleting the
> | above quoted text from the wait page.
>
> This is necessary, we would be making use of the shell too difficult for
> interactive users otherwise. But there is no particular need for an
> "interactive only" here, scripts can (though usually don't) use the jobs
> command as well (it is a convenient way to get rid of any jobs from the
> table that have finished, without knowing what they are, and without
> potentially hanging waiting for something still running).
The third item I'm referring to would just be for removal before
prompting, so obviously interactive only. There needs to be a fourth
item for removal by "jobs".
> While you're considering all of this, you might want to also consider what
> is intended to happen if a script does
>
> trap '' CHLD
>
> and how that is supposed to interact with maintenance of the jobs command,
> the wait command, and all else related.
I have a vague recollection of this coming up before, but I don't
remember whether it was in a Mantis bug or a mailing list thread.
I don't think this needs to be addressed in bug 1254; it could just
be handled via a statement on the "trap" page.
> And last, also in this area, is the question of stopped jobs and the wait
> command, and how those two are intended to interact.
The wording in my current draft makes clear that wait waits for
processes to terminate. I could, if desired, add some rationale saying
that some implementations have, as an extension, an option that allows
wait to return when a process stops.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
