Re: preventing the leading space in process substitution

[Peter Stephenson <pws@xxxxxxx>]

Bart Schaefer wrote:
> 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 mean we initially parse it the same way whether or not there's a "("
coming up next or not, and later, when we've already finished the
previous argument at that point, decide it's not a redirection after all?

> 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.

But both ">file" and "> file" work, too, so presumably if we were able
to change it so that "<(...)" and ">(...)" also worked in the middle of
an argument it wouldn't create any new problems.  We already need to
look ahead for the "(" ... but probably not at the point where we first
read the "<" and decide it's time to stop the current argument.  At that
point we'd have to look ahead two characters.  That might be the real
fly in the ointment.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070