On Sat, Jun 29, 2024 at 11:30 AM Oğuz <oguzismailuy...@gmail.com> wrote:
>
> On Saturday, June 29, 2024, Zachary Santer <zsan...@gmail.com> wrote:
>>
>> Couldn't you do the exact same thing with regular background processes
>> forked with &?
>
>
> But the shell notifies me when they terminate and reap them.
Is that relevant?
$ { sleep 5; printf 'Words\n'; } & wait -- "${!}"; printf '%s\n' "${?}"
[6] 2401
Words
[6] Done { sleep 5; printf 'Words\n'; }
0
$ { sleep 5; printf 'Words\n'; } &
[6] 2403
$ Words
<ENTER key>
[6] Done { sleep 5; printf 'Words\n'; }
$ wait -- "${!}"; printf '%s\n' "${?}"
0
$ { sleep 5; printf 'Words\n'; } & pid="${!}"
[6] 2405
$ Words
<ENTER key>
[6] Done { sleep 5; printf 'Words\n'; }
$ wait -- "${pid}"; printf '%s\n' "${?}"
0
$ wait -- "${pid}"; printf '%s\n' "${?}"
0
$ { sleep 5; printf 'Words\n'; } > >( sleep 10; IFS='' read -r; printf
'|%s|\n' "${REPLY}"; ); pid="${!}"
$ |Words|
<ENTER key>
$ wait -- "${pid}"; printf '%s\n' "${?}"
0
$ wait -- "${pid}"; printf '%s\n' "${?}"
0
With job control enabled, I can evidently wait on the same pid over
and over again with no ill effect, even if I've already been notified
that said job has terminated.
With a command like this
diff --unified -- <( command-1 ) <( command-2 )
it's safe to assume that the commands in both command substitutions
have terminated when the call to diff has terminated. In that case, if
the shell notifies you that both command substitutions have
terminated, that's redundant and annoying.
On the other hand, I'm pretty sure
command-1 | tee >( command-2 ) >( command-3 ) >( command-4 )
will terminate as soon as command-1 and tee have terminated, but the
command substitutions could still be running. If you want to run
commands like this on the command line, it still might be useful to
know when the command substitutions have terminated.
I just tend to write a script by the time things get this complicated.
