I'm talking about this:

$ readlink <(echo test)

Is pipe:[80076194] a path to the target or just indication that the file descriptor is connected to the pipe and doesn't exist in filesystem? The main reason I'm asking is due to php for one trying to dereference it:

$ strace -f php -r 'var_dump(file_get_contents($_SERVER["argv"][1]));' -- <(echo test)
[pid   654] lstat("/dev/fd/63", {st_mode=S_IFLNK|0500, st_size=64, ...}) = 0
[pid   654] readlink("/dev/fd/63", "pipe:[80095114]", 4096) = 15
[pid   654] lstat("/dev/fd/pipe:[80095114]", 0x7fff9c3628a0) = -1 ENOENT (No such file or directory)
[pid   654] lstat("/dev/fd", {st_mode=S_IFLNK|0777, st_size=13, ...}) = 0
[pid   654] readlink("/dev/fd", "/proc/self/fd"..., 4096) = 13
[pid   654] lstat("/proc/self/fd", {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0
[pid   654] lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=64, ...}) = 0
[pid   654] readlink("/proc/self", "654"..., 4096) = 3
[pid   654] lstat("/proc/654", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid   654] lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid   654] open("/proc/654/fd/pipe:[80095114]", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid   654] write(2, "PHP Warning:  file_get_contents("..., 125PHP Warning:  file_get_contents(/dev/fd/63): failed to open stream: No such file or directory in Command line code on line 1
) = 125
[pid   654] write(1, "bool(false)\n", 12bool(false)
) = 12

1 Answer 1


In short, no it does not exist.


In long:

There are 2 types of pipes in linux, named pipes (aka, fifo), and anonymous pipes.

Named pipes are created with the mkfifo (man 3 mkfifo) system call. Named pipes exist as files on the filesystem. One process opens it for reading, and another opens it for writing.

Anonymous pipes are created with the pipe (man 2 pipe) system call. Once opened, they behave exactly the same as opening a mkfifo pipe. They take up a file descriptor, one end is open for reading, the other is open for writing.

Because they take up a file descriptor, they show up in /proc/PID/fd/. But since they don't exist as an actual file anywhere, the entry in /proc/PID/fd/ has to do a little magic. So basically the pipe becomes represented as symlink with a fake target. When you open the symlink, the kernel really opens the pipe that is represented by the symlink. But since it's a symlink, and symlinks have targets, anything which tries to dereference the symlink (not implicitly via the kernel) will get back a target. It's just that this target does not point to a valid file.

Normally you cannot do this with symlinks, however the /proc filesystem is not a normal filesystem. It's a fake filesystem represented by the kernel. And since the contents are created by the kernel, the kernel can break its own rules.

  • they take up two file descriptors, aren't they?
    – x-yuri
    Commented Apr 16, 2014 at 5:20
  • @x-yuri what takes up 2 descriptors? If you're referring to when a single process has both ends of the pipe open, then yes. But how the process uses the pipe is completely up to the process. If it wants to fork off and close one end of the pipe, then it will only use 1 descriptor.
    – phemmer
    Commented Apr 16, 2014 at 12:26
  • You said "They take up a file descriptor". You made it seem as if opening a pipe returns one descriptor. Not a big deal, but it may mislead people.
    – x-yuri
    Commented Apr 16, 2014 at 12:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .