On Tue, Aug 6, 2024, 13:59 Zachary Santer <zsan...@gmail.com> wrote: > On Tue, Aug 6, 2024 at 1:19 AM Oğuz <oguzismailuy...@gmail.com> wrote: > > > > The benefit is they're separate from async jobs and don't get in your > way. `wait' waiting for the last procsub is acceptable, `wait' waiting for > a procsub that I forgot about and that won't be listed by `jobs' is not. > > I can not think of a time when I called 'wait' from the command line > that wasn't just for testing something. Even using process > substitutions on the command line is a relative rarity for me. If > we're balancing behavior on the command line against behavior in a > script, I think I'd give priority to scripting, at least here. > > Chet doesn't see much value in making process substitutions jobs, > which I guess is fine. Can we agree that if they were made jobs, > though, waiting for all of them would be acceptable? You could see > them listed and handle them however you need. > > > Procsubs occupying one slot in the shell's internal list of job statuses > is acceptable, them filling up that list and causing data loss/oom errors > is not. > > Bash is evidently already tracking all the procsub pids in their own > list, which now is always cleared when you call 'wait' without > arguments. >
where can i find this list >
