On Mon, Aug 5, 2024 at 9:54 AM Chet Ramey <chet.ra...@case.edu> wrote: > > On 7/31/24 11:48 AM, Zachary Santer wrote: > > > > $ wait -n > >( cat ) > > would hang, in the event that there are no other un-waited-for child > > processes, right? > > Yes, it will wait for the next job or procsub to terminate.
Basically the same situation as Oğuz's bug here: On Fri, Jul 5, 2024 at 2:38 PM Chet Ramey <chet.ra...@case.edu> wrote: > > On 6/29/24 10:51 PM, Zachary Santer wrote: > > > > 1) When all child processes are process substitutions: > > a. wait without arguments actually appears to wait for all of them, > > not just the last-executed one, contradicting the man page. > > This is how it is in bash-5.2. It does contradict the man page, and I > reverted it to match the man page in October, 2022, after > > https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html > > The whole business is kind of a mess. Let's see if we can figure out the > best behavior. So $! is only set to the pid for a procsub that's being redirected to/from after the command (or compound command) whose output/input is being redirected to/from it has completed? If that's the case, maybe the ideal solution for both 'wait' and 'wait -n' would be to wait for all background jobs and all procsubs that have ever been assigned to $! at that point. Bash already knows the pids for the procsubs before they are assigned to $!, right? During that time, those pids can be kept in a separate list, and then the list of all procsub pids that have ever been assigned to $! can be waited for. This still removes the potential for hanging, I think, while being more useful.
