Well, it is important to remember that <(...) or >(...) becomes a WORD openable a s a file name, like in ksh ' /dev/fd/7 ', not just a string but with implied separation, so you cannot use it in sed like this, because it looks like 2 arguments. (David Korne says he hadn't thought of it for such usage. You can strip the separation by passing it in a shell subroutine call.):

Code:

sed '
  /xyz/w '>(...)'
  /abc/w '>(...)'
  s/ .*//
 ' infile >outfile

So, some of this is silly, as 'xxx < <(yyy)' is just 'yyy | xxx'. These <() >() constructs are for places where you need a file name but want a pipe, like this:

Code:

xxx | tee >( one-parallel-process-yyy ) | second-parallel-process-zzz

In some UNIX, you have /dev/stdin, /dev/stdout and /dev/stderr, really /dev/fd/0, 1 and 2, which is enough for the occasional obstinate program with no shorthand for stdin/stdout like '-' in tar f, cat, etc. These autoomatically managed named pipes are great if there are more than 2 parallel processes. The bash management of these named pipes is flawed, BTW, bug reported -- they accumulate in /var/tmp. While the ksh in /dev/fd/# UNIX just does a pipe() call and harvests the /dev/fd/# names, the bash implementation uses mknod or mkfifo persistent named pipes, which work a bit different, a pipe() inside open() for one side and connecting to that pipe for the other side, I forget which goes first. For instance, this works to give a c progrqam a robust parallel sort, using the same named pipe twice, for input then for output. Part of the reason this works in the nature of sort, reading all input, sorting and then writing all output:

Code:

system( "rm -rf /tmp/mysort.p ; mknod /tmp/mysort.p p ; sort -o /tmp/mysort.p /tmp/mysort.p &" );
fp = fopen( "/tmp/mysort.p", wb );
while ( . . . ) { . . . ; fputs( data, data_len, fp ); }
fclose( fp );
fp = fopen( "/tmp/mysort.p", rb );
while( fgets( data, data_len, fp )){ . . . }
if ( ferror( fp )){ perror( "sort through pipe failed" ); exit( 1 ); }
fclose( fp );
system( "rm -rf /tmp/mysort.p" );

You can see the overhead of name collision, pipe creation and pipe cleanup, plus if someone else comes along and opens your pipe, it would mess things up. Named pipes were intended for a crude sort of server, where a server process keeps opening the pipe waiting for a client to open the other side the other way, and spinning off a child, somewhat like inetd spinning off server processes for every tcp connection, but it seems tricky to use the fd bidirectionally in a script, without which it is a unidirectional service, like writing a queue.

Some shells consider <() or >() subshells as your login shell's child jobs, with all the start-end notifications and such. Firing up in a subshell means they are not your children, so toss in a protective set of () if you want quiet.

Ksh also has {} to create redirection and inheritance like () but without a fork() to a subshell, but the rules are a bit demanding, so I ignore them. It turns our fork() is 10 times cheaper than execvp(), so for shell speed, count your exec's and use the built-in equivalents like read for line, pattern matching for `grep`, etc. Many nominal PERL scripts are amazingly shellish!