-1

I try to create a named pipe, however, when I store data in it, it is still empty.

$ mkfifo myfifo 
$ cat > myfifo 123 123 123 ^[[D ^C 
$ ls > myfifo ^C 
$ cat < myfifo

(no output)

Improve this question
1

3 Answers 3

Reset to default
2

You have a misunderstanding on how named pipes work.

From `mkfifo (3)...

However, it has to be open at both ends simultaneously before you can proceed to do any input or output operations on it.

As you started the write & then killed it before the read operation, the write command did not function. That is, you can only write to it, when a reader is attached.

If you start another terminal & run cat myfifo, it will wait, print any data written to the named pipe, and once the write has finished, the cat command will then end.

Improve this answer
2
  • I slightly disagree with that statement about simultaneity. You can issue input and output commands: they would just be suspended in their respective read or write system calls until their partner process begins to cooperate. Also, the cat command will only end (on EOF) when the writer process closes the fifo, not when a single write is complete. Commented Aug 19, 2024 at 16:33
  • 1
    @Paul_Pedant, both the reader and writer will block on opening the FIFO until the other end is also opened. They won't necessarily block on read() and write() since the OS will do some buffering there. Commented Aug 19, 2024 at 20:21
2

A pipe requires two processes to exist -- a writer and a reader. (In fact, at least two, as you can have more than one of each).

If you cat myFifo in one terminal, and ls > myFifo in a different terminal, you will see that readers wait for something to be written. Writers can keep writing until the pipe fills up, and readers can keep reading until the pipe is emptied.

Improve this answer
1

A pipe is not a file; it is an inter-process communication mechanism.

The FIFO entry you see in the file system is not the file. The named entry is the rendezvous point for establishing communication.

A pipe is created when two file descriptors are open on the FIFO: one for reading and one for writing. The file descriptors are connected to form a pipe, just like the two file descriptors that come from the POSIX C function pipe.

The same FIFO can create many pipes; those pipes are independent of each other.

When a FIFO is opened for reading, the call blocks until something opens the FIFO for writing, and vice versa. That's what is meant by rendezvous: the two calls to open meet at the FIFO and a unidirectional pipe is created for them, joining them together. Then, whatever is written to the write end of the pipe can be read from the read end.

Since the FIFO is only a contact point, it provides no sort of persistent storage.

The pipes themselves have a small amount of temporary storage held in RAM, allowing the writer to put some number of bytes into the pipe without being blocked. Only the reader has access to those bytes. When the reader and writer close the pipe, any unread content is gone.

Improve this answer
6
  • 1
    FIFO special file is a file. The FIFO entry the OP sees in the filesystem is certainly a file. You wrote it's not the file and I'm not sure how I'm supposed to interpret this. Can you clarify? Commented Aug 21, 2024 at 3:08
  • 1
    @KamilMaciorowski I believe the distinction here is between "regular file" and "not a regular file". The text leaves out the specific file type "regular" when it says that "a pipe is not a file". Commented Aug 21, 2024 at 3:22
  • 1
    It's possible for a named FIFO to be a file in the sense that the name in the directory is associated with an inode. The object is persistent, obviously; you can reboot and it's still there. But it's not a file which holds the pipe contents written to the file descriptor. It's a file which holds information enabling processes to rendezvous in order to be connected by pipes. Those pipes are not that file, either; they are not files at all. Commented Aug 21, 2024 at 4:48
  • 1
    I think that "The FIFO entry you see in the file system is not the file." part is a bit confusing; mainly because it refers a "the file", but it never says what that particular file is, then, if not the entry in the filesystem. I think you mean to say that a FIFO is not a persistent storage object the way a regular file is. (So in effect, there is no file.) But in the file system structure sense, a FIFO is a "file" (has an inode, etc.) the same as directories, or symlinks, or whatever. Commented Aug 21, 2024 at 12:18
  • 1
    As for "The same FIFO can create many pipes; those pipes are independent of each other.", that does apply in a sense that if both ends are closed and then reopened, the resulting pipe is "new". (Or perhaps it's just the same pipe with cleared buffers and new parties at the ends? You could check the inode number with fstat() or from /proc/pid/fd on Linux...) But you can't make multiple independent pipes from a single FIFO at the same time, you'll just get multiple readers/writers to the same pipe. Commented Aug 21, 2024 at 12:22

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.