Re: preventing the leading space in process substitution

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 10, 12:24pm, Peter Stephenson wrote:
} Subject: Re: preventing the leading space in process substitution
}
} >   mycommand -file=<(...)
} > 
} > seems to yield
} > 
} >   mycommand -file= /proc/self/fd/16
} 
} For reasons buried in history that I don't understand, the <(...) is
} parsed as a single complete argument.

I think that's because the "<" is treated like a redirection operator.
You'll note in the examples that > >(process) is even written with
spaces around the first ">" even though it works to use >>(...) with
no spaces and is more commonly written that way.

I hadn't considered this particular ramification before, and it's a
bit inconsistent that the doc for =(...) also refers to a "file passed
as an argument" although that does not have the same behavior.

I suspect this simply never came up back when process substitution was
originally introduced, because long options of the --name=value format
were pretty uncommon back then.