Mark Clarkson wrote:
On Wed, 05 Mar 2008 12:16:02 -0800 Bob McGowan <bob_mcgowan@symantec.com> wrote:Brian wrote:So can you explain exactly what the first < <( echo "$teststring" ) does exactly please?In any case, I'd be interested in knowing where you found this construct.The bash man page seems to be one of the few that can be read a thousand times and /still/ find something new in it each time! The following extract is from 'man bash' ;-) ,although what it doesn't make clear is that <(list) is preceeded by '< ', which I guess is why it's often missed. <blockquote> Process Substitution Process substitution is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. It takes the form of <(list) or >(list). The process list is run with its input or out- put connected to a FIFO or some file in /dev/fd. The name of this file is passed as an argument to the current command as the result of the expansion. If the >(list) form is used, writing to the file will pro- vide input for list. If the <(list) form is used, the file passed as an argument should be read to obtain the output of list. When available, process substitution is performed simultaneously with parameter and variable expansion, command substitution, and arithmetic expansion. </blockquote> Cheers Mark.
Interesting. But...If I do the "process substitution" using a stand alone programs, it works as described:
$ wc <(echo this is a test)
1 4 15 /dev/fd/63
And, note the '/dev/fd' "device", just as the man page describes.
If I put the above, verbatim, in a script file, it also works exactly as
described.
It "breaks" when the command used is a builtin command:
$ read list <(echo this is a test)
bash: read: `/dev/fd/63': not a valid identifier
In this case, I typed a <CR> after the first line and it "hung", in fact
it was waiting for input to the 'read' builtin. So I typed a '^D', with
the error message then following.
The string '< <(' does not appear anywhere in the bash man page, hence my failure to make the association with 'process substitution'.
But, my question is still not completely answered. What prompted Brian (or the original poster, if different), to add a second '<' to the '<('?
I suppose the next question should be what type of bug is this? Is it a documentation issue, where the '< <(...)' syntax simply needs explaining or is it a bash bug, in that a 'read list <(...)' should work?
-- Bob McGowan
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature