I’m going to guess that you probably know what a pipe symbol does on most Linux systems — passes the output of one program to a second. It’s what allows you to do things like this
dmesg | grep ATA
and find local hard drives. Or gives me my topics for the day, with
ls vimwiki/ | shuf -n1
mkfifo is part of coreutils, and allows you to name a pipe, and reuse it over and over. It might sound odd, but it works in much the same way as the symbol.
Now I have a file entry called “pipe” in my directory, marked with a “p” in the leftmost column.
kmandla@6m47421: ~$ ls -lha prw-r--r-- 1 kmandla users 0 Sep 21 07:42 pipe
Now I can jam something in that pipe, if I like.
kmandla@6m47421: ~$ ls vimwiki/ > pipe
And … apparently, nothing happens. My terminal is paused, somehow waiting for an action. The suspense is killing me. 🙄
Actually, until something collects the material in that pipe, it will pause there more or less indefinitely. So if I …
kmandla@6m47421: ~$ grep ch < pipe
The whole flood comes out, and we can all relax again. Crisis averted. 😐
It might seem rather pointless or irrelevant to name a pipe or even to make note of
mkfifo for it. But you’ve already seen the subtlety in action, and maybe just didn’t think about it.
That first terminal emulator was paused, waiting for someone to unblock the pipe. A second terminal received the data and did something with it.
So what? So … not only can you jam a program’s output into a holding area, waiting for a recipient, but that also means you can pass data between terminals with a named pipe. So if you’re waiting for one program to end, you can send the output of another into stasis, until it’s ready.
And you can pass information between different programs running in different terminals, at virtual consoles, in and out of a multiplexer … possibly even between users or across distant machines if you’re clever. It’s not the best way to do those things, but it might work in a pinch. Experiment and see.
I know named pipes are not anything new, but little things like this are the reason I wanted to sift through coreutils again. If you need a better explanation of named pipes, and you don’t mind reaching back almost 20 years, Andy Vaught’s explanation from issue #44 of Linux Journal is a great starting point. Nice to see that things haven’t changed that much since ’97. … 😉