Re: 'wait -n' with and without id arguments

[Chet Ramey]

On 8/14/24 11:22 PM, Zachary Santer wrote:

On Wed, Aug 14, 2024 at 3:22 PM Chet Ramey <chet.ra...@case.edu> wrote:

On 8/7/24 2:47 PM, Zachary Santer wrote:

Now I understand that this is because the list of terminated child
processes that 'wait -n' currently ignores is only used in the
interactive shell.

It's not, but there might be some value here.

I put a call to 'jobs' in the middle of the while loop in
wait-n-failure, and I see I can break 'wait -n' in a script called
normally by doing so. I've never called 'jobs' or used a jobspec in a
script, and I don't know why one would.

Presumably because you want to clear the jobs list of terminated jobs.

If you want the behavior of 'wait -n' to be
consistent between scripts and the interactive shell, then it should
choose one terminated child process from the list of those that is
maintained in the interactive shell, if it's nonempty, to report to
the user and to clear from that list, any time it is called.

I'm not sure returning the status of some random process from some
arbitrary point in the past is going to be valuable.

I think the value is in the consistent behavior of 'wait -n', which
this would provide. If the user is intent on running 'wait -n' without
id arguments in the interactive shell, they can ensure that child
processes forked long ago are ignored by simply calling 'wait' without
-n before moving on to what they're trying to do.

Sure, they can do that. That's a new requirement, though.

On Wed, Aug 14, 2024 at 4:44 PM Robert Elz <k...@munnari.oz.au> wrote:

   | Maybe the thing to do is to retain jobs in the job list, even after
   | they're marked as notified,

I'd do the opposite, once they're notified, they should be deleted
from the jobs table, and everywhere else.   But "notified" only happens
when the script explicitly asks (in a non-interactive shell, never because
of any other event than an appropriate command issued by the script, and
in an interactive shell, the same, or the implicit "jobs" before each PS1).

The implicit 'jobs' isn't happening before each PS1,

This isn't what POSIX says to do, anyway.

 but after each

command completes. Thus, all the

[1]   Done                    random_sleep

notifications when sourcing wait-n-failure, before it prints

3 processes waited / 8 processes forked
1 seconds

and exits.

Kind of. The `interactive shell' isn't interactive while it's not reading
input from the terminal, so the shell prints notifications when a job
terminates. This is what happens when you source a file.

So, actually only doing the implicit 'jobs' work and moving things
from the jobs table to the list of saved pids and statuses before each
PS1 *would* be a solution here.

Before the next prompt, you probably mean.

When sourcing wait-n-failure, it's
going to do all its work before any PS1 prompt.

The behavior of performing notifications and removing jobs from the table
is long-standing: it's been this way since 1999, and is a mechanism to
prevent long-running sourced scripts from filling up the jobs list (which
was a lot smaller in '99). So you need to accommodate those backwards
compatibility issues somehow.

I'm less concerned about what happens when a user types 'wait -n'
independently on the command line. The human is in the loop at that
point.

The shell is interactive at that point; different rules apply.

So basically, 'wait -n' should be implemented such that sourcing the
script with a false argument gives the same behavior as you've seen
when sourcing it with a true argument: the infinite loop.

How long should notification be deferred? Until the script completes?

That's more or less the solution I presented above. 'wait -n' without
id arguments returning the termination status of a child process that
the user has already been informed of through the implicit 'jobs'
output would also work, and might be less of a weird behavior change
for users to get over.

OK. How would you reconcile the backwards compatibility issue? There are
only three approaches.


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

OpenPGP_signature.asc
Description: OpenPGP digital signature