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.ramey@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 <kre@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    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature