A "named pipe" -- also known as a FIFO (First In, First Out) or just fifo -- is an inter-process communication mechanism that makes use of the filesystem to allow two processes to communicate with each other. In particular, it allows one of these to open one end of the pipe as a reader, and the other to open it as a writer. Let's take a look at the FIFO and how you can use it.
First, here's a real-life example of a named pipe at work. In this instance, you run a shell command like: "ls -al | grep myfile" In that example, the "ls" program is writing to the pipe, and "grep" is reading from it. Well, a named pipe is exactly that, but the processes don't have to be running under the same shell, nor are they restricted to writing to STDOUT and reading from STDIN. Instead, they reference the named pipe via the filesystem.
In the filesystem, it looks like a file of length 0 with a "p" designation
for the file type. Example:
Note that the file never grows; it's not actually a file but simply an abstraction of one type of IPC (Inter-Process Communication) provided by the kernel. As long as the named pipe is accessible, in terms of permissions, to the processes that would like to make use of it, they can read and write from it without having to worry about every using physical disk space or paying any I/O subsystem overhead.
At first glance, the utility of a named pipe is perhaps not immediately obvious, so I've come armed with more examples.
Here's a sample dilemma about dealing with the receipts generated by Web transactions. My browser of choice, Mozilla Firebird, gives me the option of either printing a page to a printer, or writing it as a Postscript file to a directory. I don't want a hardcopy, as it wastes paper, and I'll just have to file it somewhere. (If I wanted to kill a tree, I wouldn't be doing my transactions on the Web!) Also, I don't like the PostScript files, because they're large and because operating systems that ...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseLinux.com
don't have a copy of
Ghostscript installed can't view them very easily.
Instead, I want to store the page as a PDF file. This is easily accomplished with the command-line utility "ps2pdf", but I'm too lazy to write the file out as PostScript, open a shell, convert the file and then delete the PostScript file. That's no problem because the browser knows how to open a file and write to it. And, ps2pdf knows how to read from STDIN to produce PDF output.
So, in its simplest incarnation:
When I tell my browser to print the PS output to /tmp/pdffifo, the result is PDF output in ~/receipts/webprint.pdf. This is fine, but it's a "one-shot," meaning that you have to set it up each time you want to print. That's because ps2pdf exits after processing one file. For a slightly more general solution, see listing 1 at the end of this tip.
Admittedly, there are other ways to solve that Web print problem. For example, I could let the browser write the PS file and then have a daemon sweep through the directory once a day and convert everything. Unfortunately, then I'd have to wait for my PDF files, and you wouldn't have seen an example of named pipes in action.
A very pragmatic use for these rascals is made in mp3burn (http://sourceforge.net/projects/mp3burn/), a utility written in Perl that is used to burn MP3 tracks onto audio CDs. It takes advantage of named pipes by using them as the conduit between the MP3 decoders (or player) and the cdrecord, which expects WAV audio files turn to the CD. Those WAV files, which can be 700MB or so, never have to be written anywhere to the filesystem. Your system has to be fast enough to decode the MP3 to WAV and run your CD burner. But you're not paying the overhead of writing to and from the hard drive, and you don't have to worry about having almost a GB of available free space to do the burn.
Finally, there is an entire class of applications for system administrators who need to write compressed logfiles in real-time from programs that don't have compression support built-in. Even when you do have the source, do you want to spend all day re-inventing the wheel?
Listing 1
Tony Mancill is the author of "Linux Routers: A Primer for Network Administrators" from Prentice Hall PTR. He can be reached at tony@mancill.com.
