Re: waiting for process substitutions

[Zachary Santer]

On Wed, Jul 3, 2024 at 11:21 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> Process substitutions are word expansions, with a scope of a single
> command, and are not expected to survive their read/write file descriptors
> becoming invalid. You shouldn't need to `wait' for them; they're not
> true asynchronous processes.

They clearly are. The fact that it results from a word expansion is irrelevant.

Consider my original example:
command-1 | tee >( command-2 ) >( command-3 ) >( command-4 )

Any nontrivial command is going to take more time to run than it took
to be fed its input. The idea that no process in a process
substitution will outlive its input stream precludes a reading process
substitution from being useful.

And nevermind
exec {fd}< <( command )
I shouldn't do this?

To me, a process substitution is just a way to avoid the overhead of
creating named pipes.

Why should these be different in practice?

(1)
mkfifo named-pipe
child process command < named-pipe &
{
  foreground shell commands
} > named-pipe

(2)
{
  foreground shell commands
} > >( child process command )

In my actual use cases, I have:

(1)
A couple different scripts that alternate reading from multiple
different processes, not entirely unlike
sort -- <( command-1 ) <( command-2 ) <( command-3 )
except it's using exec and automatic fds.

Hypothetically, it could work like this:
{
  commands
} {fd[0]}< <( command-1 )  {fd[1]}< <( command-2 ) {fd[2]}< <( command-3 )
But then again, *I can't get the pids for the processes if I do it this way*.

( 2 )
shopt -s lastpipe
exec {fd}> >( command-2 )
command-1 |
  while [...]; do
    [...]
    if [[ ${something} == 'true' ]]; then
      printf '%s\x00' "${var}" >&"${fd}"
    fi
  done
#
exec {fd}>&-

This whole arrangement is necessary because I need what's going on in
the while loop to be in the parent shell if I'm going to use coproc
fds directly. What's going on in the process substitution will more or
less only begin when the fd it's reading from is closed, because it
involves at least one call to xargs.

But, theoretically, process substitutions shouldn't even allow for
these things? Why not give us a 'pipe' builtin at that point?