Process substitution and pipe

Question

I was wondering how to understand the following:

Piping the stdout of a command into the stdin of another is a powerful technique. But, what if you need to pipe the stdout of multiple commands? This is where process substitution comes in.

In other words, can process substitution do whatever pipe can do?

What can process substitution do, but pipe cannot?

Answer 1

A good way to grok the difference between them is to do a little experimenting on the command line. In spite of the visual similarity in use of the < character, it does something very different than a redirect or pipe.

Let's use the date command for testing.

$ date | cat
Thu Jul 21 12:39:18 EEST 2011

This is a pointless example but it shows that cat accepted the output of date on STDIN and spit it back out. The same results can be achieved by process substitution:

$ cat <(date)
Thu Jul 21 12:40:53 EEST 2011

However what just happened behind the scenes was different. Instead of being given a STDIN stream, cat was actually passed the name of a file that it needed to go open and read. You can see this step by using echo instead of cat.

$ echo <(date)
/proc/self/fd/11

When cat received the file name, it read the file's content for us. On the other hand, echo just showed us the file's name that it was passed. This difference becomes more obvious if you add more substitutions:

$ cat <(date) <(date) <(date)
Thu Jul 21 12:44:45 EEST 2011
Thu Jul 21 12:44:45 EEST 2011
Thu Jul 21 12:44:45 EEST 2011

$ echo <(date) <(date) <(date)
/proc/self/fd/11 /proc/self/fd/12 /proc/self/fd/13

It is possible to combine process substitution (which generates a file) and input redirection (which connects a file to STDIN):

$ cat < <(date)
Thu Jul 21 12:46:22 EEST 2011

It looks pretty much the same but this time cat was passed STDIN stream instead of a file name. You can see this by trying it with echo:

$ echo < <(date)
<blank>

Since echo doesn't read STDIN and no argument was passed, we get nothing.

Pipes and input redirects shove content onto the STDIN stream. Process substitution runs the commands, saves their output to a special temporary file and then passes that file name in place of the command. Whatever command you are using treats it as a file name. Note that the file created is not a regular file but a named pipe that gets removed automatically once it is no longer needed.

Answer 2

Here are three things you can do with process substitution that are impossible otherwise.

Multiple process inputs

diff <(cd /foo/bar/; ls) <(cd /foo/baz; ls)

There simply is no way to do this with pipes.

Preserving STDIN

Say you have the following:

curl -o - http://example.com/script.sh
   #/bin/bash
   read LINE
   echo "You said ${LINE}!"

And you want to run it directly. The following fails miserably. Bash is already using STDIN to read the script, so other input is impossible.

curl -o - http://example.com/script.sh | bash 

But this way works perfectly.

bash <(curl -o - http://example.com/script.sh)

Outbound process substitution

Also note that process substitution works the other way too. So you can do something like this:

(ls /proc/*/exe >/dev/null) 2> >(sed -n \
  '/Permission denied/ s/.*\(\/proc.*\):.*/\1/p' > denied.txt )

That's a bit of a convoluted example, but it sends stdout to /dev/null, while piping stderr to a sed script to extract the names of the files for which a "Permission denied" error was displayed, and then sends THOSE results to a file.

Note that the first command and the stdout redirection is in parentheses (subshell) so that only the result of THAT command gets sent to /dev/null and it doesn't mess with the rest of the line.

Answer 3

I should suppose you are talking about bash or some other advanced shell, because the posix shell does not have process substitution.

bash manual page reports:

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

In other words, and from a practical point of view, you can use an expression like the following

<(commands)

as a file name for other commands requiring a file as a parameter. Or you can use redirection for such a file:

while read line; do something; done < <(commands)

Turning back to your question, it seems to me that process substitution and pipes have not much in common.

If you want to pipe in sequence the output of multiple commands, you can use one of the following forms:

(command1; command2) | command3
{ command1; command2; } | command3

but you can also use redirection on process substitution

command3 < <(command1; command2)

finally, if command3 accepts a file parameter (in substitution of stdin)

command3 <(command1; command2)

Answer 4

If a command takes a list of files as arguments and processes those files as input (or output, but not commonly), each of those files can be a named pipe or /dev/fd pseudo-file provided transparently by process subsitution:

$ sort -m <(command1) <(command2) <(command3)

This will "pipe" the output of the three commands to sort, as sort can take a list of input files on the command line.

Answer 5

It should be noted that process substitution is not limited to the form <(command), which uses the output of command as a file. It can be in the form >(command) which feeds a file as the input to command as well. This is also mentioned in the quote of bash manual in @enzotib's answer.

For the date | cat example above, a command that uses the process substitution of the form >(command) to achieve the same effect would be,

date > >(cat)

Note that the > before >(cat) is necessary. This can again be clearly illustrated by echo as in @Caleb's answer.

$ echo >(cat)
/dev/fd/63

So, without the extra >, date >(cat) would be the same as date /dev/fd/63 which will print a message to stderr.

Suppose you have a program that only takes filenames as parameters and does not process stdin or stdout. I will use the oversimplified script psub.sh to illustrate this. The content of psub.sh is

#!/bin/bash
[ -e "$1" -a -e "$2" ] && awk '{print $1}' "$1" > "$2"

Basically, it tests that both of its arguments are files (not necessarily regular files) and if this is the case, write the first field of each line of "$1" to "$2" using awk. Then, a command that combines all that mentioned so far is,

./psub.sh <(printf "a a\nc c\nb b") >(sort)

This will print

a
b
c

and is equivalent to

printf "a a\nc c\nb b" | awk '{print $1}' | sort

but the following will not work, and we have to use process substitution here,

printf "a a\nc c\nb b" | ./psub.sh | sort

or its equivalent form

printf "a a\nc c\nb b" | ./psub.sh /dev/stdin /dev/stdout | sort

If ./psub.sh also reads stdin besides what is mentioned above, then such an equivalent form does not exist, and in that case there are nothing we can use instead of the process substitution (of course you can also use a named pipe or temp file, but that's another story).