On 5/3/22 6:52 AM, Geoff Clare via austin-group-l at The Open Group wrote:
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.

Bash implements it. I doubt very many people use it.


   | 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, ...".

Why? You can use job control notation with jobs/kill/wait even if job
control isn't enabled, which implies the presence of a job list separate
from the list of known IDs.


I think the description of the wait utility should be updated to require
removal from the list.

I agree, both the jobs list and the list of known IDs.

                        [...]


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.

That's not the current behavior. At best, it should be unspecified.

Bash, yash, mksh, dash, the NetBSD sh, and gwsh allow the `wait' builtin to
wait for any process status change (e.g., SIGSTOP). ksh93, FreeBSD sh, and
zsh force the shell to wait until the process terminates. Bash provides an
option (`wait -f') to force a wait for process termination. I didn't check
whether other shells do.


--
``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/

  • When can shells remo... Geoff Clare via austin-group-l at The Open Group
    • Re: When can sh... shwaresyst via austin-group-l at The Open Group
    • Re: When can sh... Robert Elz via austin-group-l at The Open Group
      • Re: When ca... Harald van Dijk via austin-group-l at The Open Group
      • Re: When ca... Robert Elz via austin-group-l at The Open Group
        • Re: Whe... Chet Ramey via austin-group-l at The Open Group
          • Re:... Steffen Nurpmeso 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
          • wai... Geoff Clare via austin-group-l at The Open Group
            • ... Chet Ramey via austin-group-l at The Open Group
            • ... 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

Reply via email to