User Files vs. System Files

To understand the distinction between user files and system files, recall that Linux is a multiuser OS. In principle, a single computer can host thousands of users. Consider such a computer for a moment—perhaps it’s a mainframe at a university, a large business, or a cloud-computing server. The vast majority of this computer’s users will be unfamiliar with the details of Linux system administration—they want only to use their word processors, email clients, and other applications. These users don’t need to deal with system configuration files, for example. Indeed, giving them access to such files—especially write access—could be disastrous. On a computer with 1,000 users, each of whom can change the system configuration, somebody will make a change that will bring down the computer, whether through ignorance or malice.

Of course, the issues involved in protecting the computer from its users are just a special case of more general user account issues—on that 1,000-user computer, you probably don’t want its users to be able to read and write each others’ files except in limited ways. Thus, as described in Chapter 13, “Creating Users and Groups” and Chapter 14, “Setting Ownership and Permissions,” you can set permissions on files to prevent unauthorized access.

 System files are files that control how the computer operates. They include the following:

• System startup scripts that launch servers and other important daemons
• Program files—both binary files and scripts
• Program support files, such as fonts and icons
• Configuration files that define how the system works (network configuration settings, disk layout information, and so on)
• Configuration files for most server services and other daemons
• Data storage for system programs, such as the database that describes what programs are installed
• System log files, which record normal system activity

Obviously, nontechnical users should not be able to alter system files, except perhaps indirectly. (Log files record activities such as login attempts, for instance.) Users must be able to read some types of system files, such as the fonts and icons they use, but some system files should be protected even from read access. (Users should not be able to read the 
/etc/shadow file, because it holds encrypted passwords, for instance.)

To achieve the goal of restricting ordinary users’ access to system files, such files are normally owned by root or by another system account that has a more limited purpose. For instance, many server programs rely on their own specific system accounts. System files can then be protected from unwanted access by setting permissions in some appropriate way, depending on their specific needs. Ordinary users are then unable to write to most system files, protecting these files from harm. Because root can read and write any file, you must acquire root privileges to perform most system maintenance tasks.

Immediately after installing Linux, most of the files that it contains are system files, and most of the directories and subdirectories on a fresh Linux installation are system directories. As described shortly, a few directories, such as /home and /tmp, are set aside for user files, although even these are structured or configured in such a way as to prevent problems with multiuser access.

The distinction between system files and user files exists even on single-user Linux computers, such as your personal laptop computer. This may seem strange or even frustrating; after all, if you’re the only user, and if you have root access, why bother with the distinction between system files and user files? The answer is that it provides a layer of protection against accidental or malicious damage. If a typo, a bug, or malware would, say, delete all the files on the computer, the damage is contained if this action is performed as a normal user rather than as root—a normal user can’t delete all the files on the computer. Thus the distinction between these two account types (and, by extension, these two classes of files) is useful even on a single-user computer.

The Filesystem Hierarchy Standard

Although every Linux distribution has its own unique way of doing certain things, their developers all recognize the need for some standardization in the layout of their directories. For instance, programs should be able to locate key system configuration files consistently in the same places on all distributions. If this weren’t the case, programs that rely on such features would become more complex and might not work on all distributions. To address this need, the Filesystem Hierarchy Standard (FHS) was created. Aside from Linux, some Unix-like OSs also follow the FHS to one degree or another.

One important distinction made by the FHS is between shareable files and unshareable files. Shareable files, such as user data files and program binary files, may be reasonably shared between computers. (Of course, you don’t need to share such files, but you may do so.) If files are shared, they’re normally shared through a Network File System (NFS) server. Unshareable files contain system-specific information, such as configuration files. For instance, you’re not likely to want to share a server’s configuration file between computers.

A second important distinction made by the FHS is that between static files and ­variable files. The former don’t normally change except through direct intervention by the system administrator. Most program executables are good examples of static files. Users, automated scripts, servers, or the like may change variable files. For instance, users’ home directories and mail queues are composed of variable files.

The FHS tries to isolate each directory into one cell of this 2 × 2 (shareable/unshareable × static/variable) matrix. Table 7.1 illustrates these relationships. Some directories contain subdirectories in multiple cells, but in these cases, the FHS tries to specify the status of particular subdirectories. For instance, /var is variable, and it contains some shareable and some unshareable subdirectories, as shown in Table 7.1.

The FHS comes in numbered versions. Version 3.0, the latest version as we write, was released in May 2015 (see FHS’s web page at linuxfoundation.org/collaborate/workgroups/lsb/fhs).

Important Directories and Their Contents

The FHS defines the names and purposes of many directories and subdirectories on a Linux system. Table 7.2 summarizes the most important of these directories. Most of these directories are system directories, the main exceptions being /home, /tmp, /mnt, and /media.

As an ordinary user, you will create most of your files in your home directory, which is normally a subdirectory of /home. You might also access removable media mounted at /media (or sometimes /run/media), and perhaps network resources that might be mounted elsewhere. You can use /tmp and certain subdirectories of /var, too, although most users don’t need to be aware of these locations explicitly—programs are normally hard-coded to use them for temporary files or for specific types of files, such as incoming email files. As a system administrator, you might manipulate files located in any of these directories; however, for a system administrator, /etc is particularly important, since that’s where most system configuration files reside. As you explore your computer with GUI or text-mode utilities, you should keep this directory structure in mind.

Of these directories, several individual directories or collections of them bear special attention:

The Configuration Directory  The /etc directory holds most system configuration files. Previous chapters have referred to several such files, such as /etc/fstab (which defines where partitions are mounted) and /etc/passwd (which is the primary account definition file). Many more exist. Indeed, you’ll find subdirectories in /etc to house multiple configuration files for complex subsystems and servers, such as /etc/X11 (for the X Window System) and /etc/samba (for the Samba file server).

Executable Directories  Program files reside mainly in /sbin, /bin, /usr/sbin, and 
/usr/bin. (Additional directories can house program files on some systems. Most notably, /usr/local/sbin and /usr/local/bin hold locally compiled programs.)

 Library Directories  Libraries are collections of programming functions that can be useful to many programs. They’re stored in separate files to save disk space and RAM when programs run, and they enable easy updates to library files without reinstalling all of the programs that rely on them. In Linux, most libraries reside in /lib and /usr/lib, although some can reside elsewhere (such as /usr/local/lib) on some systems.

If you’ve administered Windows computers, you should be aware of an important difference between Windows and Linux: in Windows, it’s common for a program binary, its configuration files, and all of its support files to reside in a single directory tree that belongs to the program, such as C:Program FilesSomeProgram. In Linux, by contrast, most of 
a program’s key files are likely to reside in standard locations that are shared with other programs and to be scattered about. For instance, the program’s executable might be in /usr/bin, related libraries in /usr/lib, configuration files in /etc or in users’ home direc­tories, and so on. This works well in Linux because Linux’s packaging systems, described in Chapter 9, “Exploring Processes and Process Data,” keep track of where a package’s many files go, enabling you to delete or upgrade a package easily. Linux has the advantage of simplifying the path, which is the list of directories in which program files reside. (Paths also exist for libraries and man pages.) If you’re used to looking for files in program-specific locations, though, adjusting to the Linux system can be awkward. The key is to use your package system to identify where a package’s files reside; for instance, typing rpm -ql someprogram shows where every file in the someprogram package resides on an RPM-based system.

Obtaining File Listings

 To manipulate files, it’s helpful to know what they are. The ls command, whose name is short for list, provides you with this information. The ls command displays the names of files in a directory. If you pass it no options, it shows the files in the current directory; however, you can pass it options as well as file or directory specifications. This command supports a huge number of options; consult its man page for details. Table 7.3 summarizes the most important ls options.

You may optionally give ls one or more file or directory names, in which case ls displays information about those files or directories, as in this example:

$ ls -F /usr /bin/ls
/bin/ls
 
/usr:
X11R6/  games/                include/  man/    src/
bin/    i386-glibc20-linux/   lib/      merge@  tmp@
doc/    i486-linux-libc5/     libexec/  sbin/
etc/    i586-mandrake-linux/  local/    share/

This output shows both the /bin/ls program file and the contents of the /usr directory. The latter consists mainly of subdirectories, indicated by a trailing slash (/) when -F is used. By default, ls creates a listing that’s sorted by filename, as shown in this example. Note, though, that uppercase letters (as in X11R6) always appear before lowercase letters (as in bin).

One of the most common ls options is -l, which creates a long directory listing like this:

$ ls -l t*

-rwxr-xr-x  1 rich rich      111 Aug 13 13:48  test
-rw-r--r--  1 rich rich   176322 Jul 16 09:34  thttpd-2.20b-1.i686.rpm
-rw-r--r--  1 rich rich  1838045 Jul 24 18:52  tomsrtbt-1.7.269.tar.gz
-rw-r--r--  1 rich rich  3265021 Aug 22 23:46  tripwire.rpm

This output includes permission strings (such as -rwxr-xr-x), ownership (an owner of rich and a group of rich for all of these files), file sizes, and file creation dates in addition to the filenames. This example also illustrates the use of the * wildcard, which matches any string; thus, t* matches any filename that begins with t.

Changing Directories

 The cd command changes the current directory in which you’re working. Although your current directory doesn’t matter for many commands, it does matter when you begin to refer to files. As described in the next section, “Using Absolute and Relative File References,” some types of file references depend on your current directory.

When you change your current directory, your shell’s prompt may change (depending on your distribution’s settings), to something like this:

[rich@essentials ~]$  cd /usr/bin

[rich@essentials bin]$

The default configurations for many distributions display only the final part of the current directory—bin rather than /usr/bin in the preceding example. If you need to know the complete path of your current location, you can use pwd:

$ pwd

/usr/bin

Linux uses a slash (/) character as a directory separator. If you’re familiar with Windows, you may know that Windows uses a backslash () for this purpose. Don’t confuse the two! In Linux, a backslash serves as a “quote” or “escape” character to enter otherwise hard-to-specify characters, such as spaces, as part of a filename. Also, take note that a slash isn’t a legal character in a Linux filename for this reason.

Using Absolute and Relative File References

As described in Chapter 6, “Managing Hardware,” Linux uses a unified directory tree, which means that all files can be located relative to a single root directory, which is often referred to using the slash (/) character. If your disk contains multiple partitions, one of these devices becomes the root filesystem, and others are mounted at some location within the overall directory tree. The same thing happens when you mount a USB flash drive, DVD, or other removable disk device. The result might resemble Figure 7.1, which shows a subset of the directories found on a typical Linux installation, along with a couple of removable media types. Most commonly, removable media appear as subdirectories of the /media directory, but some Linux distributions prefer to use /run/media. Most subdirectories can be split off as separate partitions or even placed on separate disks. In Figure 7.1, the /home directory is on its own partition, but it’s accessed in exactly the same way as it would be if it were part of the root (/) partition.

When pointing to files and directories in commands, you can refer to them in three ways:

Absolute References  Absolute file references are relative to the root (/) directory, as in 
/home/fred/afile.txt to refer to the afile.txt file in Fred’s home directory. Such references always begin with a slash (/) character.

Home Directory References  The tilde (~) character refers to the user’s home directory. If a filename begins with that character, it’s as if the path to the user’s home directory were substituted. Thus, for Fred, ~/afile.txt is equivalent to /home/fred/afile.txt.

Relative References  Relative file references are relative to the current directory. Thus, if Fred is working in his home directory, afile.txt refers to /home/fred/afile.txt. Relative references can include subdirectories, as in somedir/anotherfile.txt. In Linux, every directory includes a special hidden reference (..), which refers to its parent directory. Thus, if Sally is working in /home/sally, she can refer to Fred’s afile.txt file as ../fred/afile.txt.

To better understand these concepts, try these operations:

1. Launch a new shell, or use an existing one.
2. Type cd ~ to change into your home directory.
3. Type cat /etc/fstab to view this configuration file using an absolute file reference. Its contents should appear in your terminal.
4. Type pwd to view your current directory. It will probably be /home​/ yourusername, where yourusername is—you guessed it!—your username.
5. Type cat ../../etc/fstab to view this configuration file using a relative file reference. The first .. in this command refers to /home, and the second refers to the root (/) directory. (If your home directory is in an unusual location, you may need to adjust the number of ../ elements in this command, which is why we had you use pwd to find your current directory in the previous step.)
6. Type cat ~/../../etc/fstab to view this configuration file using a home directory reference.

Of course, steps 5 and 6 use rather awkward file references; in real life, you’d probably use an absolute file reference to access /etc/fstab from your home directory. If you were 
in a subdirectory of /etc, though, typing ../fstab would be slightly easier than typing /etc/fstab; and typing ~/afile.txt would be easier than typing the complete path to your home directory.

Creating Files

Normally, you create files using the programs that manipulate them. For instance, you might use a graphics program to create a new graphics file. This process varies from one program to another, but GUI programs typically use a menu option called Save or Save As to save a file. Text-mode programs provide similar functionality, but the details of how it’s done vary greatly from one program to another.

 One program deserves special mention as a way to create files: touch. You can type 
this program’s name followed by the name of a file that you want to create, such as 
touch newfile.txt to create an empty file called newfile.txt. Ordinarily, you don’t need to do this to create a file of a particular type, since you’ll use a specialized program to do the job. Sometimes, though, it’s helpful to create an empty file just to have the file itself—for instance, to create a few “scratch” files to test some other command.

If you pass touch the name of a file that already exists, touch updates that file’s access and modification time stamps to the current date and time. This can be handy if you’re using a command that works on files based on their access times, and you want the program to treat an old file as if it were new. You might also want to do this if you plan to distribute a collection of files and you want them all to have identical time stamps.

You can use a number of options with touch to modify its behavior. The most important of these are as follows:

Don’t Create a File  The -c or --no-create option tells touch not to create a new file if one doesn’t already exist. Use this option if you want to update time stamps but you do not want to create an empty file accidentally, should you mistype a filename.

Set the Time to a Specific Value  You can use -d string or --date= string to set the date of a file to that represented by the specified string, which can take any number of forms. For instance, touch -d "July 4 2019" afile.txt causes the date stamps on afile.txt to be set to July 4, 2019. You can achieve the same effect with -t [[ CC] YY] MMDDhhmm[. ss], where [[ CC] YY] MMDDhhmm[ . ss] is a date and time in a specific numeric format, such as 201907041223 for 12:23 p.m. on July 4, 2019.

Consult the man page for touch to learn about its more obscure options.

Copying Files

 If you’re working in a text-mode shell, the cp command copies a file. (Its name is short for copy.) To use it, you can pass cp a source filename and a destination filename, a destination directory name, or both. Table 7.4 outlines these three ways to use the command. Although the example filenames in Table 7.4 suggest that the original file be in your current working directory, this need not be the case; orig.txt could include a directory specification, such as /etc/fstab or ../afile.txt.

The critical point to understand is how the destination filename is specified. This can be less than obvious in some cases, since file and directory specifications can look alike. For instance, consider the following command:

$ cp outline.pdf ~/publication

This command can produce any of three results:

• If ~/publication is a directory, the result is a file called ~/publication/outline.pdf.

• If ~/publication is a file, the result is that this file will be replaced by the contents of outline.pdf.
• If ~/publication doesn’t yet exist, the result is a new file, called ~/publication, which is identical to the original outline.pdf.

Keeping these results straight can be confusing if you’re new to command-line file copying. We encourage you to experiment by creating a test directory using mkdir (described later, in “Creating Directories”), creating subdirectories in this directory, and copying files into this test directory tree using all of these methods of referring to files. (This is the type of situation where touch can be handy for creating test files.)

The cp command provides many options for modifying its behavior. Some of the more useful options enable you to modify the command’s operation in helpful ways:

Force Overwrite  The -f or --force option forces the system to overwrite any existing files without prompting.

Use Interactive Mode  The -i or --interactive option causes cp to ask you before overwriting any existing files.

Preserve Ownership and Permissions  Normally, the user who issues the cp command owns a copied file and uses that account’s default permissions. The -p or --preserve option preserves ownership and permissions, if possible.

Perform a Recursive Copy  If you use the -R or --recursive option and specify a directory as the source, the entire directory, including its subdirectories, is copied. Although -r also performs a recursive copy, its behavior with files other than ordinary files and directories is unspecified. Most cp implementations use -r as a synonym for -R, but this behavior isn’t guaranteed.

Perform an Archive Copy  The -a or --archive option is similar to -R, but it also preserves ownership and copies links as is. The -R option copies the files to which symbolic links point rather than the symbolic links themselves. (Links are described in more detail later in this chapter, in “Using Links.”)

Perform an Update Copy  The -u or --update option tells cp to copy the file only if the original is newer than the target or if the target doesn’t exist.

Moving and Renaming Files

 In a text-mode shell you use the same command, mv, both to move and rename files and directories. Its use is similar to that of cp; for instance, if you wanted to move outline.pdf to ~/publication, you would type:

$ mv outline.pdf ~/publication

If you specify a filename with the destination, the file will be renamed as it’s moved. If you specify a filename and the destination directory is the same as the source directory, the file will be renamed but not moved. In other words, mv’s effects are much like cp’s, except that the new file replaces, rather than supplements, the original.

Behind the scenes, mv does the following:

• When the source and target are on the same filesystem, mv rewrites directory entries without actually moving the file’s data.

• When you move a file from one filesystem to another, mv copies the file and then deletes the original file.

The mv command takes many of the same options as cp does. From the earlier list, --preserve, --recursive, and --archive don’t apply to mv, but the others do.

Using Links

 Sometimes it’s handy to refer to a single file by multiple names. Rather than create several copies of the file, you can create multiple links to one file. Linux supports two types of links, both of which are created with the ln command:

Hard Link  A hard link is a duplicate directory entry. Both entries point to the same file. Because they work by tying together low-level filesystem data structures, hard links can exist only on a single filesystem. In a hard link scenario, neither filename holds any sort of priority over the other; both tie directly to the file’s data structures and data. Type ln origname linkname, where origname is the original name and linkname is the new link’s name, to create a hard link.

Symbolic Link  A symbolic link (aka soft link) is a file that refers to another file by name. That is, the symbolic link is a file that holds another file’s name, and when you tell a program to read to or write from a symbolic link file, Linux redirects the access to the original file. Because symbolic links work by filename references, they can cross filesystem boundaries. Type ln -s origname linkname to create a symbolic link.

You can identify links in long directory listings (using the -l option to ls) in a couple of ways. The following example illustrates this:

$ ln report.odt hardlink.odt

$ ln -s report.odt softlink.odt

$ ls -l

total 192
-rw-r--r-- 2 rich users 94720 Sep 10 11:53 hardlink.odt
-rw-r--r-- 2 rich users 94720 Sep 10 11:53 report.odt
lrwxrwxrwx 1 rich users    10 Sep 10 11:54 softlink.odt -> report.odt

This example began with a single file, report.odt. The first two commands created two links, a hard link (hardlink.odt) and a symbolic link (softlink.odt). Typing ls -l shows all three files. The original file and the hard link can be identified as links by the presence of the value 2 in the second column of the ls -l output; this column identifies the number of filename entries that point to the file, so a value higher than 1 indicates that a hard link exists. The symbolic link is denoted by an l (a lowercase L, not a digit 1) in the first character of the softlink.odt file’s permissions string (lrwxrwxrwx). Furthermore, the symbolic link’s filename specification includes an explicit pointer to the linked-to file.

Both types of links are useful for referring to files by multiple names or in multiple directories. For instance, if you write a letter that you send to multiple recipients, you might want to store copies in directories devoted to each recipient. In such a situation, either type of link will probably work fine, but each type has implications. Most importantly, if you use symbolic links, deleting the original file makes the file completely inaccessible; the symbolic links remain but point to a nonexistent file. If you use hard links, by contrast, you must delete all copies of the file to delete the file itself. This is because hard links are duplicate directory entries that point to the same file, whereas symbolic links are separate files that refer to the original file by name.

If you modify a file by accessing its soft link, or by any hard-linked name, you should be sure that the program you use will modify the original file. Some programs create a backup of the original file that you can use to recover the original in case you find that your changes were in error. Most editors do this in such a way that the backup is a new file, and they write changes to the original file, thus affecting it as well as the link. Some programs, though, rename the original file and then write a new file with the changes. If a program does this and you’ve accessed the file via a link, the linked-to file will be unaffected by your changes. If in doubt, test your program to be sure that it does what you expect.

If you want to create a link to a directory, be aware that you can normally do this only via symbolic links. Hard links between directories are potentially dangerous in terms of low-level filesystem data structures, so the ln utility permits only the superuser to create such links. Even then, most filesystems disallow hard links between directories, so in practice even root usually can’t create them. Any user can create symbolic links to a directory, though.

Linux installations make use of links (mostly symbolic links) in various places. For instance, system startup scripts are often referred to via symbolic links located in directories dedicated to specific startup conditions, known as runlevels. Runlevel management is beyond the scope of this book.

Deleting Files

The rm command deletes files in a text-mode shell. As you might expect, you pass the names of one or more files to this command:

$ rm outline.pdf outline.txt

This example deletes two files, outline.pdf and outline.txt. If you want to delete an entire directory tree, you can pass rm the -r, -R, or --recursive option along with a directory name:

$ rm -r oldstuff/

The -i option causes rm to prompt before deleting each file. This is a useful safety measure. You can use the -f (--force) option to override this setting, if -i is configured as the default. Several other options to rm exist; consult its man page to learn about them.

It’s important to realize that rm does not implement any functionality like a file manager’s “trash can.” After you delete a file with rm, it’s gone, and you can’t recover it except by using low-level filesystem tools—a topic that’s well beyond the scope of this book. Thus, you should be careful when using rm—and even more careful when using it with its -r option or as root!

Using Wildcards

 A wildcard is a symbol or set of symbols that stands in for other characters. You can use wildcards to refer to files. (Using wildcards is also sometimes called globbing.) Three classes of wildcards are common in Linux:

?  A question mark (?) stands in for a single character. For instance, b??k matches book, balk, buck, or any other four-character filename that begins with b and ends with k.

*  An asterisk (*) matches any character or set of characters, including no character. For instance, b*k matches book, balk, and buck just as does b??k. b*k also matches bk, bbk, and backtrack.

Bracketed Values  Characters enclosed in square brackets ([]) normally match any character within the set. For instance, b[ao][lo]k matches balk and book but not buck. You can also specify a range of values; for instance, b[a-z]ck matches back, buck, and other four-letter filenames of this form whose second character is a lowercase letter. This differs from b?ck—because Linux treats filenames in a case-sensitive way and because ? matches any character (not just any letter), b[a-z]ck doesn’t match bAck or b3ck, although b?ck matches both of these filenames.

Wildcards are implemented in the shell and passed to the command that you call. For instance, if you type ls b??k and that wildcard matches the three files balk, book, and buck, the result is precisely as if you’d typed ls balk book buck.

Understanding Case Sensitivity

 Linux’s native filesystems are case-sensitive, which means that filenames that differ only in case are distinct files. For instance, a single directory can hold files called afile.txt, Afile.txt, and AFILE.TXT, and each is a distinct file. This case sensitivity also means 
that, if you type a filename, you must enter it with the correct case—if a file is called afile.txt but you type its name as Afile.txt, the program you’re using will tell you that the file doesn’t exist. This is different from what happens in Windows or (usually) in macOS, in which filenames that differ only in case are treated identically. In these OSs, you can’t have two files that differ only in case in the same directory, and you can specify a filename using any case variant that you like. Windows also creates a short filename (eight characters with an optional three-character extension) for every file with a longer name in order to help out older software that works only with such filenames. Linux doesn’t create such alternate filenames.

Case sensitivity is primarily a function of the filesystem, not of the operating system. Thus if you access a non-Linux filesystem (on a removable disk, a non-Linux partition on a dual-boot computer, or using a network filesystem), you may find that case-insensitive rules will apply. This is particularly likely when accessing File Allocation Table (FAT) and New Technology File System (NTFS) volumes, which are common on Windows computers, external hard disks, and USB flash drives. A further twist on this rule is that many Linux programs, such as Bash, assume case sensitivity even on case-insensitive filesystems. Features such as command completion, described in Chapter 5, “Getting to Know the Command Line” may work only if you use the case in which filenames are recorded, even on case-insensitive filesystems.

Ordinarily, case sensitivity creates few real problems, particularly if you use GUI programs that enable you to point-and-click to select files. You should be aware of these issues, however, when copying files or directories to FAT, NTFS, HFS+, or other case-insensitive filesystems. If a directory that you want to copy contains files with names that differ only in case, you’ll end up with a disk that contains just one of the offending files.

Creating Directories

 You can use the mkdir command to create a directory. Ordinarily, you’ll use this command by typing the name of one or more directories following the command:

$ mkdir newdir

$ mkdir dirone newdir/dirtwo

The first example creates just one new directory, newdir, which will then reside in the current directory. The second example creates two new directories: dirone and newdir/dirtwo. In this example, mkdir creates dirtwo inside the newdir directory, which was created with the preceding command.

In most cases, you’ll use mkdir without options, other than the name of a directory, but you can modify its behavior in a few ways:

Set Mode  The -m mode or --mode= mode option causes the new directory to have the specified permission mode, expressed as an octal number. (Chapter 14 describes these topics in more detail.)

Create Parent Directories  Normally, if you specify the creation of a directory within a directory that doesn’t exist, mkdir responds with a No such file or directory error and doesn’t create the directory. If you include the -p or --parents option, though, mkdir creates the necessary parent directory. For instance, typing mkdir first/second returns 
an error message if first doesn’t exist, but typing mkdir -p first/second succeeds, creating both first and its subdirectory, second.

Deleting Directories

 The rmdir command is the opposite of mkdir; it destroys a directory. To use it, you normally type the command followed by the names of one or more directories that you want 
to delete:

$ rmdir dirone

$ rmdir newdir/dirtwo newdir

These examples delete the three directories created by the mkdir commands shown earlier.

Like mkdir, rmdir supports few options, the most important of which handle these tasks:

Ignore Failures on Non-Empty Directories  Normally, if a directory contains files or 
other directories, rmdir doesn’t delete it and returns an error message. With the 
--ignore-fail-on-non-empty option, rmdir still doesn’t delete the directory, but it 
doesn’t return an error message.

Delete Tree  The -p or --parents option causes rmdir to delete an entire directory tree. For instance, typing rmdir -p newdir/dirtwo causes rmdir to delete newdir/dirtwo, then newdir. You could use this command rather than the second one shown earlier to delete both of these directories.

You should understand that rmdir can delete only empty directories; if a directory contains any files at all, it won’t work. (You can use the -p option, however, to delete a set of nested directories, as long as none of them holds any nondirectory files.) Of course, in real life you’re likely to want to delete directory trees that hold files. In such cases, you can use the rm command, described earlier in “Deleting Files,” along with its -r (or -R or --recursive) option:

$ rm -r newdir

This command deletes newdir and any files or subdirectories that it might contain. This fact makes rm and its -r option potentially dangerous, so you should be particularly cautious when using it.

Managing Directories

Directories are just special files—they’re files that hold other files. This means you can use most of the file manipulation tools described elsewhere in this chapter to manipulate directories. There are some caveats, though:

• You can use touch to update a directory’s time stamps, but you can’t use touch to create a directory; mkdir handles that task.
• You can use cp to copy a directory; however, you must use the -r, -R, --recursive, -a, or --archive option to copy the directory and all its contents.
• You can use mv to move or rename a directory.
• You can use ln with its -s option to create a symbolic link to a directory. No common Linux filesystem supports hard links to directories, though.

As an example, suppose that you have a directory in your home directory called 
Music/Satchmo, which contains Louis Armstrong music files. You want to reorganize this directory so that the files appear under the performer’s last name, but you want to retain access to the files under the name Satchmo, since your music players refer to them this way. You could type the following commands to achieve this goal:

$ cd ~/Music

$ mv Satchmo Armstrong

$ ln -s Armstrong Satchmo

Alternatively, you could omit the first command and specify the complete path to each of the directories or links in the mv and ln commands. As written, the first two of these commands rename the ~/Music/Satchmo directory to ~/Music/Armstrong. The final command creates a symbolic link, ~/Music/Satchmo, that points to ~/Music/Armstrong.