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

[Zachary Santer]

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.

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

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

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. When sourcing wait-n-failure, it's
going to do all its work before any PS1 prompt. Same deal if a user
wants to call a function with 'wait -n' in it from the command line,
invoke the edit-and-execute-command readline command, or just type a
bunch of different commands separated by semicolons into a single
command line.

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.

On Wed, Aug 14, 2024 at 3:24 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 8/9/24 9:29 PM, Zachary Santer wrote:
> >
> > 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.

wait-n-failure
Description: Binary data