Linux with Operating System Concepts

computers
rather than between processes.
Yet another type of file entity is the 
named pipe
. You have already explored the pipe in 
earlier chapters. The named pipe differs in that it exists beyond the single usage that occurs 
when we place a pipe between two Linux commands.
To create a named pipe, you define it through the 
mkfifo
operation. The expression 
FIFO is short for “first-in-first-out.” FIFO is often used to describe a queue (waiting line) 
as queues are generally serviced in a first-in, first-out manner. In this case, mkfifo creates a 
FIFO, or a named pipe. Once the pipe exists, you can assign it to be used between any two 
processes. Unlike an ordinary pipe that must be used between two Linux processes in a 
single command, the named pipe can be used in separate instructions.
Let us examine the usage of a named pipe. First, we define our pipe:
mkfifo a_pipe
This creates a file entity called a_pipe. As with any file or directory, a_pipe has permis-
sions, user and group owner, creation/modification date, and a size (of 0). Now that the 
pipe exists, we might use the pipe in some operation:
ps aux 
>
a_pipe
Unlike performing 
ps aux
, or even 
ps aux | more
, this instruction does not seem 
to do anything when executed. In fact, our terminal window seems to hang as there is no 
output but neither is the cursor returned to us. What we have done is opened one end of the 
pipe. But until the other end of the pipe is open, there is nowhere for the 
ps aux
instruc-
tion’s output to “flow.”
To open the other end of the pipe, we might apply an operation (in a different terminal 
window since we do not have a prompt in the original window) like:
cat a_pipe
Now, the contents “flow” from the ps aux command through the pipe to the cat com-
mand. The output appears in the second terminal window and when done, the command 
line prompt returns in the original window.

---

The Linux File System
◾
397
You might ask why use a named pipe? In fact, the pipe is being used much like an ordi-
nary pipe. Additionally, the named pipe does roughly the same thing as a domain socket—
it is a go between for IPC. There are differences between the named pipe and pipe and 
between the named pipe and the domain socket. The named pipe remains in existence. 
We can call upon the named pipe numerous times. Notice here that the source program is 
immaterial. We can use a_pipe no matter what the source program is.
Additionally, the mkfifo instruction allows us to fine tune the pipe’s performance. 
Specifically, we can assign permissions to the result of the pipe. This is done using the option 
–M 
mode
where 
mode
is a set of permissions such as 
–M 600
or 
–M u
=
rwx,g
=
r,o
=
r
. 
The difference between the named pipe and the domain socket is a little more obscure. 
The named pipe always transfers one byte (character) at a time. The domain socket is not 
limited to byte transfers but could conceivably transfer more data at a time.
10.3.3 Links as File Types
The final file type is the link. There are two forms of links: hard links and soft (or symbolic) 
links. A hard link is stored in a directory to represent a file. It stores the file’s name and the 
inode number. When creating a new hard link, it duplicates the original hard link, storing 
the new link in a different directory. The symbolic link instead merely creates a pointer to 
point at the original hard link.
The difference between the two types of links is subtle but important. If you were to cre-
ate a symbolic link and then attempt to access a file through the symbolic link rather than 
the original link, you are causing an extra level of indirect access. The operating system 
must first access the symbolic link, which is a pointer. The pointer then provides access to 
the original file link. This file link then provides access to the file’s inode, which then pro-
vides access to the file’s disk blocks (we discuss inodes in the next subsection).
It may sound like symbolic links are a drawback and we should only use hard links. This 
is not true though for several reasons. First, hard links cannot link files together that exist 
on separate partitions. Additionally, hard links can only link together files whereas sym-
bolic links can link directories and other file system entities together. On the positive side 
for hard links, they are always up to date. If you move the original object, all of the hard 
links are modified at the same time. If you delete or move a file that is linked by a symbolic 
link, the file’s (hard) link is modified but not the symbolic link; thus you may have an out-
of-date symbolic link. This can lead to errors at a later time.
In either case, a link is used so that you can refer to a file that is stored in some other 
location than the current directory. This can be useful when you do not want to add the 
file’s location to your PATH variable. For instance, imagine that user zappaf has created 
a program called my_program, which is stored in ~zappaf. You want to run the program 
(and zappaf was nice enough to set its permissions to 755). Rather than adding /home/
zappaf to your PATH, you create a symbolic link from your home directory to ~zappaf/
my_program. Now you can issue the my_program command from your home directory.
One last comment
: You can determine the number of hard links that exist for a single 
file when you perform an 
ls –l
. The integer value after the permissions is the number of 
hard links. This number will never be less than 1 because with no hard links, the file will 

---

398
◾
Linux with Operating System Concepts
not exist. However, the number could be far larger than 1. Deleting any of the hard links 
will reduce this number. If the number becomes 0, then the file’s inode is returned to the 
file system for reuse, and thus access to the file is lost with its disk space available for reuse.
If you have a symbolic link in a directory, you will be able to note this by its type and 
name when viewing the results of an 
ls –l
command. First, the type is indicated by an 
‘
l
’ (for link) and the name will contain the symbolic link’s name, an arrow (
-
>
) and the 
location of the file being linked. Unfortunately, unlike the hard link usage, if you were to 
use 
ls –l
on the original file, you will not see any indication that it is linked to by sym-
bolic links.
10.3.4 File Types
Collectively, all of these special types of entities are treated like files in the following ways:
• Each item is listed when you do an ls.
• Each item can be operated upon by file commands such as mv, cp, rm and we can 
apply redirection operators on them.
• Each item is represented in the directory by means of an inode.
You can determine a file’s type by using ls -l (long listing). The first character of the 
10-character permissions is the file’s type. In Linux, the seven types are denoted by the 
characters in Table 10.1.
To illustrate the types of files, see Figure 10.3. Here, we see excerpts from three direc-
tories. At the top is a subdirectory of /tmp. The /tmp directory stores files created by run-
ning software. In many (most) cases, the types of files created in /tmp are domain sockets, 
whose type is denoted by an ‘s’. The next group of items listed come from the /dev direc-
tory where you can find character-type devices (c), block-type devices (b), directories (d), 
symbolic links (l), and regular files (-), although no regular files are shown in the figure. 
Finally, the last six entries come from a user’s file space where we see a named pipe (p), 
several regular files with a variety of permissions, and a directory.
Every file (no matter the type, e.g., regular file, character type, block type, named pipe) 
is stored in a directory. The directory maintains the entities stored in it through a list. The 
listing is a collection of hard and soft links. A hard link of a file stores the file’s name and 
TABLE 10.1 
Characters for Each Type of File