It might be easiest to view it like so:

  $ echo <(echo 1) <(echo 2)
  /dev/fd/63 /dev/fd/62

The shell spawns two commands connected to pipes, then replaces those with a file that represents the other (read) side of that pipe.

The command above with >(grep something) does the same thing, just with the other end of a pipe.

It is called process substitution and specific to Bash (not POSIX shell compliant). The output of the commands in parenthesis will become runtime (file) inputs for the diff command.

More: https://www.gnu.org/software/bash/manual/html_node/Process-S...

<(command) is being replaced by a path to a file which contains the output of the command:

  $ ls <(echo A)
  /dev/fd/63

  $ cat <(echo A)
  A

So

  diff <(command1) <(command2)

becomes

  diff /dev/fd/62  /dev/fd/63

The <(foo | bar) syntax evaluates to a file path, e.g.

  $ echo <(echo hi)
  /dev/fd/63

If a program reads from that file path, it gets the output of the command chain.

  $ cat <( (echo foo; echo bar) | grep bar )
  bar

Of course, that's a silly example. But that explains how the diff example works, since it's the same idea: diff just reads from the two "files".

EDIT: Heh, 5 different replies within the same 60 second window.

it does[0] you are redirecting stdout of both of the subprocesses (the things in brackets) to the stdin of the diff command (I think it creates two different input streams, that diff knows how to compare).

[0] http://tldp.org/LDP/abs/html/process-sub.html

Yes. You're directing the STDOUT of each command as a FILE into diff. Diff takes two files, thus the duplication.

diff compares files line by line, here we just redirect the output of cmd1 and cmd2 via <, so they serve as 'proxies' for the file-args diff expects

you might want to read into redirection on the commandline, it's amazingly powerful