mmastrac on Bug #915: Please help

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 6y

Yes, because “cat” can use either STDIN or a file as input:

https://github.com/coreutils/coreutils/blob/master/src/cat.c...

It’s an intentional design decision.

mmastrac 6y

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).

thaumasiotes 6y

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.

shawnz 6y

I think the point is that the directory listing is the same, not that cat supports both syntaxes.

Comments