Re: waiting for process substitutions

[Zachary Santer]

On Tue, Aug 6, 2024 at 9:09 AM Oğuz <oguzismailuysal@gmail.com> wrote:
>
> On Tue, Aug 6, 2024 at 2:58 PM Zachary Santer <zsanter@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.

How bash is actually used should guide its development. What are you
doing where you might want to call 'wait' from the interactive shell?

> > 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.

In a script, a child process being a job or not makes no difference,
from the shell programmer's perspective, unless you've got job control
on for some reason. The only difference it would make, as far as I can
tell, would be simplifying the implementation of 'wait', given that
there would be nothing besides jobs that it would be expected to wait
for. And with that implementation of 'wait', naturally, all procsubs
would be waited for by a call without id arguments.

> 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.

Only as much noise as how many procsubs you expand on the command line.

Frankly, I was surprised that coprocs were jobs. But if there are
benefits to treating every asynchronous process besides elements of a
pipeline the same, within bash's implementation, I'm all for it.