Hello Yoann, I honestly only gave your reproducer a cursory look before I sent that last email.
Hopefully you received Chet's reply, but in case you didn't, here's that: On Mon, Sep 28, 2026 at 11:26 AM Chet Ramey <[email protected]> wrote: > > On 9/27/26 11:49 AM, Yoann wrote: > > Hello Mister Ramey > > > > > > So I am answering your answers and questions here : > > -So if I use the same names as you did I do have the bash process T that > > launch a background job process S and the wait command is executed in the > > bash process T ; and the wait command is waiting on the background job > > process S. > > -Also when I took the time to read the bash source code I did fall on the > > command you wrote (wait/waitpid/wait3/wait4) and I do understand this job > > management depends on how system calls are made (you cannot do what you > > want) > > -I did wrote a minimal reproducer with as few external dependencies as > > possible as you asked. I did add this bash script in this email. > > Consider the following scenario (I have not tested your reproducer in > detail). You are running this script in a command substitution subshell, > a non-interactive shell, which does not have job control enabled. You are > attempting to run the `jobs' builtin to determine how many background jobs > you have remaining to wait for. However, the shell is allowed to remove > jobs from the table after the user has been notified of their disposition, > and it does this when the shell is not interactive and job control is not > enabled. One thing that counts as notifying is running `jobs'. > > So, it's easy to imagine jobs `disappearing' from the table because more > than one job terminates between the time you call `jobs' and the time you > call `wait'. The shell removes more than one job from the jobs table, you > wait for one of them, and you have two fewer outstanding jobs the next > time you check. > > Keeping the count and pid of any outstanding jobs yourself, and using > `set -o posix' as Zack recommended, should overcome this issue. So basically, don't try to use the 'jobs' builtin to track things for you. It's not supposed to work the way you thought it would. You need to track things for yourself. I refactored your reproducer to do that and generally look a little more like I wrote it. I used non-forking command substitutions (lines 57 and 104), which were introduced in bash 5.3, so it won't run in anything older. You probably won't need those in your ffmpeg scripts, but they are nice to have. Let me know if you have any questions. I think there's a real bug report here, though. I modified the script a bit more to chase that down. Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: cygwin Compiler: gcc Compilation CFLAGS: -g -O2 uname output: MSYS_NT-10.0-26300 ZackFramework16 3.6.10-3ea87a50.x86_64 2026-09-28 15:20 UTC x86_64 Msys Machine Type: x86_64-pc-cygwin Bash Version: 5.4 Patch Level: 0 Release Status: devel Commit: 1c20880e16 Description: - multiple background processes - 'wait -n -p' - no PID arguments - called from within a non-forking command substitution * in POSIX mode: Waits for each PID twice in every case except when the whole thing is nested within a single forking command substitution. In that case, there tends to be somewhat fewer than 16 loop iterations for the 8 background processes. * in default mode: Waits for each PID once in every case except when the whole thing is nested within a single forking command substitution. I wouldn't have expected to need POSIX mode when job control is disabled and the 'jobs' command is not called. Some similar error may be occuring within the 'wait' command in other invocations, but those might be harder to test than this one. Repeat-By: Run ./wait_results_2.sh with the '-o posix' arguments to 'set' commented out or not. On Mon, Sep 28, 2026 at 3:30 PM Yoann <[email protected]> wrote: > > Hello Mister Santer > > > I did subscribe into the two mail lists as you asked. Help-bash and > Bug-bash. > > > Yes I do understand that a command substitution is a child process of > the "top parent" process. > > The parent process (or the shell) has the process ID of 12345 and when > it read the command $() ; this process 12345 create a new process 12346 > with the attribute of being a child of 12345. > > And I do understand that when I call the "&" command it does create a > new process (that is also a child of the process where it has been called) > > Let's say the parent process 12345 call one "sleep" function with the > "&" command. So a new child process 12347 will be created but the parent > process 12345 will continue to execute while the child process 12347 > will execute on his side. > > > Now as you said the wait command can only "monitor" or "watch" the > direct child process of the parents process. So if I understand it well > I shall execute the "wait" command in the same process where I did call > the "&" command. > > And according to me it is what I did in my reproducer... I could be > missing something but my reproducer has 2 functions where I did write > the "&" command and the "wait" command in both of them. > > > Also one thing. I did write that to mister Ramey. If you execute the > reproducer I did send you. > > You would see that the results 1, 3, 5 and 7 are reliable (child process > are waited and managed correctly) but the results 2, 4, 6 and 8 are not > reliable (some of those child process are lost). > > By results I mean the results of the functions shown in your terminal. > > And the results 1, 3, 5 and 7 use a direct calling or explicit sub-shell > calling of the functions. But the results 2, 4, 6 and 8 are executed > through a command substitution. That is why I do think it is related to > the command substitution... > > And also by using the "set -o posix" command (you can find it at the top > of my reproducer) it does NOT solve the issue. It changes the global > behavior slighly but it does not solve the issue even when executed in > bash 5.3. > > > You can ask me as you want if you need help. > > > Best regards
wait_results_2.sh
Description: Bourne shell script
