On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer <zsan...@gmail.com> wrote: > 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.
This belongs on your personal blog. > 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. Making them jobs would be a bad idea. There are two major use cases of process substitutions: 1. Piping the output of a script to a command from within the script itself. 2. Creating one-off FIFO files in scripts and on the command line. Neither use case would be improved if procsubs were made jobs. And it'd create too much noise for miniscule benefit. > Bash is evidently already tracking all the procsub pids in their own > list, which now is always cleared when you call 'wait' without > arguments. It's okay as long as the user has his CHILD_MAX remembered jobs. If too much memory is used for procsubs or if they stay in memory for too long that should be fixed.
