On 7/20/24 1:50 PM, Zachary Santer wrote:
Was "waiting for process substitutions"For context: $ git show -q origin/devel commit 6c703092759ace29263ea96374e18412c59acc7f (origin/devel) Author: Chet Ramey <chet.ra...@case.edu> Date: Thu Jul 18 16:48:17 2024 -0400 job control cleanups; wait -n can return terminated jobs if supplied pid arguments; wait -n can wait for process substitutions if supplied pid arguments On Thu, Jul 18, 2024 at 12:36 PM Chet Ramey <chet.ra...@case.edu> wrote:On 7/14/24 8:40 PM, Zachary Santer wrote:On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey <chet.ra...@case.edu> wrote:There is code tagged for bash-5.4 that allows `wait -n' to look at these exited processes as long as it's given an explicit set of pid arguments.I agree with all the knowledgeable people here telling you that the way 'wait -n' is still implemented in bash-5.3-alpha is obviously wrong, but I also want to point out that the way you plan to change its behavior in bash-5.4 still won't allow Greg's example below to work reliably.OK, but how would you do that? If a job has already terminated, and been removed from the jobs list, how would you know that `wait -n' without pid arguments should return it? There can be an arbitrary number of pids on the list of saved pids and statuses -- the only way to clear it using wait is to run `wait' without arguments. You can say not to remove the job from the jobs list, which gets into the same notification issues that originally started this discussion back in January, and I have made a couple of changes in that area in response to the original report that I think will address some of those. But once you move the job from the jobs list to this list of saved pids, `wait' without -n or pid arguments won't look for it any more (and will clear the list when it completes). Why should `wait -n' without pid arguments do so?'wait' without -n or pid arguments doesn't look in the list of saved pids and statuses simply because it would serve no purpose for it to do so. The return status will be 0, no matter how any child process terminated, or even if there never was a child process. * For 'wait -n', on the other hand: "If the -n option is supplied, wait waits for a single job from the list of ids or, if no ids are supplied, any job, to complete and returns its exit status." People are going to naturally expect 'wait -n' without pid arguments to return immediately with the exit status of an already-terminated child process, even if they don't provide id arguments. In order to do so, 'wait -n' obviously has to look in the list of saved pids and statuses.
I think the part you're missing is that processes get moved to this list after the user has already been notified of their termination status.
If two jobs happen to finish simultaneously, the next call to wait -n should reap one of them, and then the call after that should reap the other. That's how everyone wants it to work, as far as I've seen. *Nobody* wants it to skip the job that happened to finish at the exact same time as the first one, and then wait for a third job. If that happens in the loop above, you'll have only 4 jobs running instead of 5 from that point onward.
OK, if you can send me an example that shows bash doing the wrong thing here, we can talk about it.
* Or in any case, 'wait' without arguments as the first command in a script seemed to have a termination status of 0. But then the manual says: "If none of the supplied arguments is a child of the shell, or if no arguments are supplied and the shell has no unwaited-for children, the exit status is 127."
That describes the behavior of `wait -n' without arguments; it immediately
follows the sentence introducing the -n option.
--
``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
