3 ms·

It's not actually a pipe. >, < and | are IO redirection commands; but of those only | is a pipe. Pipes specifically "pipe" the STDOUT of one command as the STDI

It's not actually a pipe. >, < and | are IO redirection commands; but of those only | is a pipe. Pipes specifically "pipe" the STDOUT of one command as the STDIN of another. The other two instead point a command to the file descriptor of the output of another. This is explained in more detail here: https://askubuntu.com/questions/172982/what-is-the-difference-between-redirection-and-pipe https://askubuntu.com/questions/172982/what-is-the-differenc...

mmastrac 7y ago
On linux at least, these two constructions are effectively identical from the view of the "piped" process. # cat <(ls -l /proc/self/fd/) total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20519634] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23611/fd/ # ls -l /proc/self/fd/ | cat - total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20518265] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23621/fd/
- deaddodo 7y ago
  Yes, because “cat” can use either STDIN or a file as input: https://github.com/coreutils/coreutils/blob/master/src/cat.c#L663..L679 https://github.com/coreutils/coreutils/blob/master/src/cat.c... It’s an intentional design decision.
  - mmastrac 7y ago
    I think we're probably in agreement, but we're getting caught up on the definition of "piping". In my case I'm using it to describe the use of a kernel pipe object. In your case, you are using it to describe the higher-level concept of connection from one processes stdout to another process's stdin (or something along those lines).
  - shawnz 7y ago
    I think the point is that the directory listing is the same, not that cat supports both syntaxes.
  - thaumasiotes 7y ago
    Repeating shawnz's comment more explicitly: you said that the mechanism used by <() is "not actually a pipe". What is `pipe:[20519634]` doing in the output of `cat <(ls -l /proc/self/fd/)`? What it looks like is ls having its stdout (fd 1) directed to a pipe.
TheDong 7y ago
It is a pipe, just for a different definition of pipe. | is the pipe operator in sh for doing a shell "pipeline". However, the parent comment is referring to a linux pipe as in pipe(7) [0]. One easy way to see this is with the following: $ ls -l <(echo foo) lr-x------ 1 user group Jan 12 01:23 /proc/self/fd/16 -> 'pipe:[2937585]' As you can see, that command created a fd (16) which referred to a pipe (pipe:[2937585]). Those file descriptors were created using the pipe(2)[1] call by the shell, so it seems fine to refer to them to pipes. I'll also note that <() / >() are _not_ using the "redirection operator". They're actually distinct operators for "process substitution"[2] in bash terminology. They look similar to redirects, but they're not the same operator, so that stack overflow answer isn't really relevant. [0]: http://man7.org/linux/man-pages/man7/pipe.7.html http://man7.org/linux/man-pages/man7/pipe.7.html [1]: http://man7.org/linux/man-pages/man2/pipe.2.html http://man7.org/linux/man-pages/man2/pipe.2.html [2]: https://tldp.org/LDP/abs/html/process-sub.html https://tldp.org/LDP/abs/html/process-sub.html
- 0x8BADF00D 7y ago
  On POSIX systems, the line between file and pipe doesn’t exist. If you create a named pipe w/ mknod or mkfifo, you would interact with the named pipe as you would a normal file. Or block/character device. Etc. In case of unnamed pipe the fds just exist as long as the process is running, then it disappears. Point is it’s irrelevant what you refer to as pipe, at the end of the day some file-like object is either written to or read from. And really, that file-like object is actually just a buffer.
  - azernik 7y ago
    The line absolutely exists, it's just behind an abstraction barrier for read(), write(), and close() calls. The creator of a pipe calls pipe() or pipe2(), and holders of the fd can get access to pipe-specific features with fcntl() and ioctl().

mmastrac 7y ago

On linux at least, these two constructions are effectively identical from the view of the "piped" process. # cat <(ls -l /proc/self/fd/) total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20519634] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23611/fd/ # ls -l /proc/self/fd/ | cat - total 0 lrwx------ 1 root root 64 Jan 12 15:02 0 -> /dev/pts/0 l-wx------ 1 root root 64 Jan 12 15:02 1 -> pipe:[20518265] lrwx------ 1 root root 64 Jan 12 15:02 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jan 12 15:02 3 -> /proc/23621/fd/

deaddodo 7y ago
Yes, because “cat” can use either STDIN or a file as input: https://github.com/coreutils/coreutils/blob/master/src/cat.c#L663..L679 https://github.com/coreutils/coreutils/blob/master/src/cat.c... It’s an intentional design decision.
- mmastrac 7y ago
  I think we're probably in agreement, but we're getting caught up on the definition of "piping". In my case I'm using it to describe the use of a kernel pipe object. In your case, you are using it to describe the higher-level concept of connection from one processes stdout to another process's stdin (or something along those lines).
- shawnz 7y ago
  I think the point is that the directory listing is the same, not that cat supports both syntaxes.
- thaumasiotes 7y ago
  Repeating shawnz's comment more explicitly: you said that the mechanism used by <() is "not actually a pipe". What is `pipe:[20519634]` doing in the output of `cat <(ls -l /proc/self/fd/)`? What it looks like is ls having its stdout (fd 1) directed to a pipe.

TheDong 7y ago

It is a pipe, just for a different definition of pipe. | is the pipe operator in sh for doing a shell "pipeline". However, the parent comment is referring to a linux pipe as in pipe(7) [0]. One easy way to see this is with the following: $ ls -l <(echo foo) lr-x------ 1 user group Jan 12 01:23 /proc/self/fd/16 -> 'pipe:[2937585]' As you can see, that command created a fd (16) which referred to a pipe (pipe:[2937585]). Those file descriptors were created using the pipe(2)[1] call by the shell, so it seems fine to refer to them to pipes. I'll also note that <() / >() are _not_ using the "redirection operator". They're actually distinct operators for "process substitution"[2] in bash terminology. They look similar to redirects, but they're not the same operator, so that stack overflow answer isn't really relevant. [0]: http://man7.org/linux/man-pages/man7/pipe.7.html http://man7.org/linux/man-pages/man7/pipe.7.html [1]: http://man7.org/linux/man-pages/man2/pipe.2.html http://man7.org/linux/man-pages/man2/pipe.2.html [2]: https://tldp.org/LDP/abs/html/process-sub.html https://tldp.org/LDP/abs/html/process-sub.html

0x8BADF00D 7y ago
On POSIX systems, the line between file and pipe doesn’t exist. If you create a named pipe w/ mknod or mkfifo, you would interact with the named pipe as you would a normal file. Or block/character device. Etc. In case of unnamed pipe the fds just exist as long as the process is running, then it disappears. Point is it’s irrelevant what you refer to as pipe, at the end of the day some file-like object is either written to or read from. And really, that file-like object is actually just a buffer.
- azernik 7y ago
  The line absolutely exists, it's just behind an abstraction barrier for read(), write(), and close() calls. The creator of a pipe calls pipe() or pipe2(), and holders of the fd can get access to pipe-specific features with fcntl() and ioctl().