Was "Process substitution documentation request" on [email protected][1].
On Thu, Jun 25, 2026 at 6:29 PM Zachary Santer <[email protected]> wrote: > > On Thu, Jun 25, 2026 at 7:32 AM Greg Wooledge <[email protected]> wrote: > > > > sudowrap() { > > local arg max=3 > > for arg; do > > if [[ $arg =~ ^/dev/fd/([0-9]+)$ ]]; then > > max=$(( BASH_REMATCH[1]+1 > max ? BASH_REMATCH[1]+1 : max )) > > fi > > done > > sudo --close-from="$max" "$@" > > } > > > hobbit:~$ sudowrap diff <(echo 1) <(echo 2) > > Alright, you win. And that's fairly simple to boot. This just gave me an idea. Remember some time ago I was complaining that there was no way to collect all the pids for the process substitutions when more than one appears in a command, only to realize that the new function substitutions could do it for you in every case[2][3]? Well, by golly! Who needs funsubs? procsub-wait-solution-2: ``` #!/usr/bin/env bash shopt -s lastpipe main () { local -a -i wait_pids=() tee_three declare -p wait_pids wait -- "${wait_pids[@]}" declare -p SECONDS } tee_three () { tee_two >( declare -p BASHPID; sleep 15 ) } tee_two () { wait_pids+=( "${!}" ) tee_one "${@}" >( declare -p BASHPID; sleep 10 ) } tee_one () { wait_pids+=( "${!}" ) tee_zero "${@}" >( declare -p BASHPID; sleep 5 ) } tee_zero () { wait_pids+=( "${!}" ) printf '%s\n' {0..10} | tee "${@}" | sleep 2 # } main ``` $ ./procsub-wait-solution-2 declare -i BASHPID="2006" declare -i BASHPID="2007" declare -i BASHPID="2008" declare -ai wait_pids=([0]="2006" [1]="2007" [2]="2008") declare -i SECONDS="15" That's not convoluted at all! /s Works like a charm, though. And considering that the function at the top of the call stack, in this case tee_zero (), is just handling a bunch of filenames, no reason you couldn't use those in redirections. >From [4]: On Fri, Jul 12, 2024 at 11:48 AM Chet Ramey <[email protected]> wrote: > > On 7/9/24 6:12 AM, Zachary Santer wrote: > > > > Maybe a single middle-ground array variable, listing the pids of all > > child processes forked (and not waited on) since the last time the > > array variable was referenced, would be more easily implemented. > > Maybe in some future version. Chet... you know you want to... Not about to promise a patch, but what would a good name for such a variable be? [1] https://lists.gnu.org/archive/html/help-bash/2026-06/msg00045.html [2] https://lists.gnu.org/archive/html/bug-bash/2024-10/msg00041.html [3] https://lists.gnu.org/archive/html/bug-bash/2024-12/msg00128.html [4] https://lists.gnu.org/archive/html/bug-bash/2024-07/msg00105.html
