On Thu, Jun 06, 2019 at 03:18:16PM -0400, Chet Ramey wrote:
> > If ID is not given, waits for all currently active child
> > *processes*, and the return status is zero.
>
> OK, so the wording is the issue? What would work better? We could use
> the "known to the shell" wording POSIX does, or "background jobs" or
> even "running jobs" that some other shells use.
"running jobs" seems fine to me, but with bash 5 I guess it would
have to be extended to "running jobs and the last started process
substitution if one exists and it is still running".
> > But I still think it would be nice if `wait` and `jobs` behaved more
> > consistently. To sum up, here are the two points I find to be
> > inconsistent:
> >
> > 1. `wait` takes into account process substitutions (or at least the
> > last one) but `jobs` does not.
>
> Because they're not jobs. They can't be the target of any of the
> commands that operate on jobs, can't be moved between the foreground
> and background, and don't have a job id. Plus the issues with the
> controlling terminal.
Okay, that makes sense.
> > 2. `wait` takes into account only the last process substitution but
> > takes into account all processes of other kinds, not just the
> > last of their kind (and this is not documented in the help or the
> > man page).
>
> So you'd now like wait without arguments to wait on all process
> substitutions?
Well, I guess I kind of liked the old behaviour (i.e. not waiting
for process substitutions at all). It just seemed less confusing.
> I don't think that's what most people want.
Maybe not indeed...
> It seems like a reasonable compromise between waiting for none
> (pre-bash-5.0 behavior) and waiting for all. If you are interested
> in waiting for all the process substitutions, you can collect the
> PIDs by getting $! after each one starts, and wait for them
> explicitly.
...but I don't really see the use case. If the PID can be retrieved
from `$!`, why not just `wait $!`? Because one might want to wait
for all background jobs _and_ the last process substitution? Sure,
this might help in this case:
... >(...) & ...; wait
But it won't in the following case, with a second process
substitution:
... >(...) >(...) & ...; wait
I guess what I'm trying to get at is that this new feature of `wait`
is lacking in generality, and that makes it confusing _and_ not all
that useful in, well, the general case.
And, by the way, I get an error message with the following command
in bash 5.0.7:
$ echo >(sleep 5) >(sleep 1); pstree -p $BASHPID; wait
/dev/fd/63 /dev/fd/62
bash(10730)-+-bash(30435)---sleep(30437)
|-bash(30436)---sleep(30439)
`-pstree(30438)
bash: wait_for: No record of process 30435
I also found out, while tinkering around, that it is not possible to
wait for any process substitution but the last one, even though this
should technically be possible in the underlying C implementation
since in my test examples the process substitution in question is
indeed a (direct) child process of the shell:
$ echo > >(sleep 5); a=$!; echo > >(sleep 1); pstree -p $BASHPID; wait $a
$!
bash(30240)-+-bash(30241)---sleep(30243)
|-bash(30242)---sleep(30245)
`-pstree(30244)
./bash: wait: pid 30241 is not a child of this shell
This behaviour is present in both bash 4 and 5. Whether this is to
be considered a bug/undesirable or not...
Hopefully, I haven't come across as overly argumentative and
critical, and if I have, it is only because I actually really like
bash and have been using it daily, as a shell or as a scripting
language, for more than ten years. So, for what it's worth, thank
you very much for all the great work that you've put into
maintaining and improving bash for all these years.
--
mwnx
GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726
ipfs.io/ipfs/QmV4tMgNmqewgcPgX4ktAbrA9jHeiM2DhEFSB4BKxwj75c
