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