IT 363 Unix Shell Programming

MODULE I

Introduction to Unix:- Architecture of Unix

What is Unix ?

The Unix operating system is a set of programs that act as a link between the

computer and the user.

The computer programs that allocate the system resources and coordinate all the

details of the computer's internals is called the operating system or the kernel.

Users communicate with the kernel through a program known as the shell. The shell

is a command line interpreter; it translates commands entered by the user and

converts them into a language that is understood by the kernel.

Unix was originally developed in 1969 by a group of AT&T employees Ken

Thompson, Dennis Ritchie, Douglas McIlroy, and Joe Ossanna at Bell Labs.

There are various Unix variants available in the market. Solaris Unix, AIX,

HP Unix and BSD are a few examples. Linux is also a flavor of Unix which

is freely available.

Several people can use a Unix computer at the same time; hence Unix is called

a multiuser system.

A user can also run multiple programs at the same time; hence Unix is a

multitasking environment.

Unix Architecture

Here is a basic block diagram of a Unix system −

The main concept that unites all the versions of Unix is the following four basics −

Kernel − The kernel is the heart of the operating system. It interacts with the

hardware and most of the tasks like memory management, task scheduling

and file management.

Shell − The shell is the utility that processes your requests. When you type in

a command at your terminal, the shell interprets the command and calls the

program that you want. The shell uses standard syntax for all commands. C

Shell, Bourne Shell and Korn Shell are the most famous shells which are

available with most of the Unix variants.

Commands and Utilities − There are various commands and utilities which

you can make use of in your day to day activities. cp, mv, catand grep, etc.

are few examples of commands and utilities. There are over 250 standard

commands plus numerous others provided through 3rd party software. All the

commands come along with various options.

Files and Directories − All the data of Unix is organized into files. All files

are then organized into directories. These directories are further organized

into a tree-like structure called the filesystem.

Features of Unix

Some key features of the Unix architecture concept are:

Unix systems use a centralized operating system kernel which manages system

and process activities.

All non-kernel software is organized into separate, kernel-managed processes.

Unix systems are preemptively multitasking: multiple processes can run at the

same time, or within small time slices and nearly at the same time, and any

process can be interrupted and moved out of execution by the kernel. This is

known as thread management.

Files are stored on disk in a hierarchical file system, with a single top location

throughout the system (root, or "/"), with both files and directories,

subdirectories, sub-subdirectories, and so on below it.

With few exceptions, devices and some types of communications between

processes are managed and visible as files or pseudo-files within the file system

hierarchy. This is known as everything is a file. However, Linus Torvalds states

that this is inaccurate and may be better rephrased as "everything is a stream of

bytes".[1]

The UNIX operating system supports the following features and capabilities:

Multitasking and multiuser

Programming interface

Use of files as abstractions of devices and other objects

Built-in networking (TCP/IP is standard)

Persistent system service processes called "daemons" and managed by init or

inet

Introduction to unix file system

A file system is a logical collection of files on a partition or disk. A partition is a

container for information and can span an entire hard drive if desired.

Your hard drive can have various partitions which usually contain only one file

system, such as one file system housing the /file system or another containing

the /home file system.

One file system per partition allows for the logical maintenance and management

of differing file systems.

Everything in Unix is considered to be a file, including physical devices such as

DVD-ROMs, USB devices, and floppy drives.

Directory Structure

Unix uses a hierarchical file system structure, much like an upside-down tree, with

root (/) at the base of the file system and all other directories spreading from there.

A Unix filesystem is a collection of files and directories that has the following

properties −

It has a root directory (/) that contains other files and directories.

Each file or directory is uniquely identified by its name, the directory in which

it resides, and a unique identifier, typically called an inode.

By convention, the root directory has an inode number of 2 and

the lost+found directory has an inode number of 3. Inode

numbers 0and 1 are not used. File inode numbers can be seen by specifying

the -i option to ls command.

It is self-contained. There are no dependencies between one filesystem and

another.

The directories have specific purposes and generally hold the same types of

information for easily locating files. Following are the directories that exist on the

major versions of Unix −

S.No. Directory & Description

1 /

This is the root directory which should contain only the directories

needed at the top level of the file structure

2 /bin

This is where the executable files are located. These files are available

to all users

3 /dev

These are device drivers

4 /etc

Supervisor directory commands, configuration files, disk

configuration files, valid user lists, groups, ethernet, hosts, where to

send critical messages

5 /lib

Contains shared library files and sometimes other kernel-related files

6 /boot

Contains files for booting the system

7 /home

Contains the home directory for users and other accounts

8 /mnt

Used to mount other temporary file systems, such

as cdrom and floppy for the CD-ROM drive and floppy diskette

drive, respectively

9 /proc

Contains all processes marked as a file by process number or other

information that is dynamic to the system

10 /tmp

Holds temporary files used between system boots

11 /usr

Used for miscellaneous purposes, and can be used by many users.

Includes administrative commands, shared files, library files, and

others

12 /var

Typically contains variable-length files such as log and print files and

any other type of file that may contain a variable amount of data

13 /sbin

Contains binary (executable) files, usually for system administration.

For example, fdisk and ifconfig utlities

14 /kernel

Contains kernel files

Navigating the File System

Now that you understand the basics of the file system, you can begin navigating to

the files you need. The following commands are used to navigate the system −

S.No. Command & Description

1 cat filename

Displays a filename

2 cd dirname

Moves you to the identified directory

3 cp file1 file2

Copies one file/directory to the specified location

4 file filename

Identifies the file type (binary, text, etc)

5 find filename dir

Finds a file/directory

6 head filename

Shows the beginning of a file

7 less filename

Browses through a file from the end or the beginning

8 ls dirname

Shows the contents of the directory specified

9 mkdir dirname

Creates the specified directory

10 more filename

Browses through a file from the beginning to the end

11 mv file1 file2

Moves the location of, or renames a file/directory

12 pwd

Shows the current directory the user is in

13 rm filename

Removes a file

14 rmdir dirname

Removes a directory

15 tail filename

Shows the end of a file

16 touch filename

Creates a blank file or modifies an existing file or its attributes

17 whereis filename

Shows the location of a file

18 which filename

Shows the location of a file if it is in your PATH

You can use Manpage Help to check complete syntax for each command mentioned

here.

The df Command

The first way to manage your partition space is with the df (disk free)command.

The command df -k (disk free) displays the disk space usage in kilobytes, as

shown below −

$df -k

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/vzfs 10485760 7836644 2649116 75% /

/devices 0 0 0 0% /devices

$

Some of the directories, such as /devices, shows 0 in the kbytes, used, and avail

columns as well as 0% for capacity. These are special (or virtual) file systems, and

although they reside on the disk under /, by themselves they do not consume disk

space.

The df -k output is generally the same on all Unix systems. Here's what it usually

includes −

S.No. Column & Description

1 Filesystem

The physical file system name

2 kbytes

Total kilobytes of space available on the storage medium

3 used

Total kilobytes of space used (by files)

4 avail

Total kilobytes available for use

5 capacity

Percentage of total space used by files

6 Mounted on

What the file system is mounted on

You can use the -h (human readable) option to display the output in a format that

shows the size in easier-to-understand notation.

The du Command

The du (disk usage) command enables you to specify directories to show disk

space usage on a particular directory.

This command is helpful if you want to determine how much space a particular

directory is taking. The following command displays number of blocks consumed

by each directory. A single block may take either 512 Bytes or 1 Kilo Byte

depending on your system.

$du /etc

10 /etc/cron.d

126 /etc/default

6 /etc/dfs

...

$

The -h option makes the output easier to comprehend −

$du -h /etc

5k /etc/cron.d

63k /etc/default

3k /etc/dfs

...

$

Mounting the File System

A file system must be mounted in order to be usable by the system. To see what is

currently mounted (available for use) on your system, use the following command

−

$ mount

/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)

proc on /proc type proc (rw,nodiratime)

devpts on /dev/pts type devpts (rw)

$

The /mnt directory, by the Unix convention, is where temporary mounts (such as

CDROM drives, remote network drives, and floppy drives) are located. If you need

to mount a file system, you can use the mount command with the following syntax

−

mount -t file_system_type device_to_mount directory_to_mount_to

For example, if you want to mount a CD-ROM to the directory /mnt/cdrom, you

can type −

$ mount -t iso9660 /dev/cdrom /mnt/cdrom

This assumes that your CD-ROM device is called /dev/cdrom and that you want to

mount it to /mnt/cdrom. Refer to the mount man page for more specific

information or type mount -h at the command line for help information.

After mounting, you can use the cd command to navigate the newly available file

system through the mount point you just made.

Unmounting the File System

To unmount (remove) the file system from your system, use the umountcommand

by identifying the mount point or device.

For example, to unmount cdrom, use the following command −

$ umount /dev/cdrom

The mount command enables you to access your file systems, but on most modern

Unix systems, the automount function makes this process invisible to the user and

requires no intervention.

User and Group Quotas

The user and group quotas provide the mechanisms by which the amount of space

used by a single user or all users within a specific group can be limited to a value

defined by the administrator.

Quotas operate around two limits that allow the user to take some action if the

amount of space or number of disk blocks start to exceed the administrator defined

limits −

Soft Limit − If the user exceeds the limit defined, there is a grace period that

allows the user to free up some space.

Hard Limit − When the hard limit is reached, regardless of the grace period,

no further files or blocks can be allocated.

There are a number of commands to administer quotas −

S.No. Command & Description

1 quota

Displays disk usage and limits for a user of group

2 edquota

This is a quota editor. Users or Groups quota can be edited using this

command

3 quotacheck

Scans a filesystem for disk usage, creates, checks and repairs quota

files

4 setquota

This is a command line quota editor

5 quotaon

This announces to the system that disk quotas should be enabled on

one or more filesystems

6 quotaoff

This announces to the system that disk quotas should be disabled for

one or more filesystems

7 repquota

This prints a summary of the disc usage and quotas for the specified

file systems

Basic Unix Commands – General-purpose utilities, vi editor

MODULE II

The Unix file system has a hierarchical (or tree-like) structure with its highest

level directory called root (denoted by /, pronounced slash). ... Similar to the

concept of the process parent-child relationship, allfiles on a Unix system are

related to one another. That is, files also have a parent-child existence.

File Types in Unix: Ordinary or Regular Files, Directories, Device (Special) Files,

Links, Named Pipes, and Sockets

Ordinary or Regular Files

A large majority of the files found on UNIX and Linux systems are ordinary files.

Ordinary files contain ASCII (human-readable) text, executable program binaries,

program data, and more.

Directories

A directory is a binary file used to track and locate other files and directories. The

binary format is used so that directories containing large numbers of filenames can

be search quickly.

Device (Special) Files

Device or special files are used for device I/O on UNIX and Linux systems. They

appear in a file system just like an ordinary file or a directory.

On UNIX systems there are two flavors of special files for each device, character

special files and block special files. Linux systems only provide one special file for

each device.

When a character special file is used for device I/O, data is transferred one

character at a time. This type of access is called raw device access.

When a block special file is used for device I/O, data is transferred in large fixed-

size blocks. This type of access is called block device access.

Links

A link is a tool used for having multiple filenames that reference a single file on a

physical disk. They appear in a file system just like an ordinary file or a directory.

Like special files, links also come in two different flavors. There are hard links and

symbolic links.

Hard links do not actually link to the original file. Instead they maintain their own

copy of the original file's attributes (i.e. location on disk, file access permissions,

etc.). If the original file is deleted, its data can still be accessed using the hard link.

On the other hand, symbolic links contain a pointer, or pathname, to the original

file. If the original file is deleted, its data can no longer be accessed using the

symbolic link, and the link is then considered to be a stale link.

Named Pipes

Named pipes are tools that allow two or more system processes to communicate

with each other using a file that acts as a pipe between them. This type of

communication is known as interprocess communication, or IPC for short.

Sockets

Sockets are also tools used for interprocess communication. The difference

between sockets and pipes is that sockets will facilitate communication between

processes running on different systems, or over the network.

With so many different types of files, it's often wise to identify a file's type before

performing any operation with it. The ls -l command and the file command are

useful for determining file types.

Consider the long listing of the livefirelabs1 file:

-rw-rw-r-- 1 student1 student1 0 Jun 27 18:55 livefirelabs1

The first character of the first field indicates the file type. In this example, the first

character is a - (hyphen) indicating that livefirelabs1 is an ordinary or regular file.

Consider the long listing of the live1 file:

lrwxrwxrwx 1 student1 student1 13 Jun 27 17:57 live1 -> livefirelabs1

The first character of the first field is the letter l indicating live1 is a symbolic link.

The following is a table listing what characters represent what types of files:

- Ordinary or Regular File

d Directory

c Character special file

b Block special file

l Symbolic link

p Named pipe

s Socket

The file command is also helpful for determining file types. The syntax for this

command is:

$ file filename

If the file is an ordinary file, the file command will also indicate what the contents

of the file is.

Unix: Operations on files

Copying and moving files

Download file

The exercises in this chapter makes use of a file named “unixpast.txt”. You can

download a copy of this file from here. (Right click, select “Save Link As…” from

the menu, and make sure you save it in your exercisesdirectory.)

Copy file (cp)

The command cp file1 file2 makes a copy of file1 and writes it to file2.

$ mv unixpast.txt unixpast.copy

Move file or directory (mv)

The command mv file1 file2 moves (or renames) file1 to file2.

To move a file from one place to another, use the mv command. This has the effect

of moving rather than copying the file.

It can also be used to rename a file, by moving the file to the same directory, but

giving it a different name.

We are now going to move the file unixpast.copy to your backup directory.

First, change working directory to your exercises directory. Then, inside

the exercises directory, type

$ mv unixpast.copy repository

Type ls and ls repository to see if it has worked.

Exercise

Create a backup of your unixpast.txt file by copying it to a file called unixpast.copy

Removing files and directories

Remove rm (), rmdir (remove directory)

To delete (remove) a file, use the rm command. As an example, we are going to

create a copy of the unixpast.txtfile then delete it.

Inside your exercises directory, type the following sequence of commands:

$ cp unixpast.txt tempfile.txt

$ ls

$ rm tempfile.txt

$ ls

You can use the rmdir command to remove a directory (make sure it is empty

first). Try to remove the repository directory. You will not be able to since Unix

will not let you remove a non-empty directory.

Exercise

Create a directory called emphemera in your exercises directory, using the

command mkdir. Check that it exists. Then remove it using the command rmdir.

Check that it is gone

Displaying the contents of a file on the screen

cat (concatenate)

The command cat can be used to display the contents of a text file on the screen.

Type:

$ cat unixpast.txt

As you can see, the file is longer than than the size of the window, so it scrolls past

making it unreadable.

less

The command less writes the contents of a file onto the screen a page at a time.

Type

$ less unixpast.txt

Press [space] if you want to see another page, and q if you want to quit reading. As

you can see, less is more convenient than cat for viewing long files.

Using less, you can search though a text file for a keyword (pattern). For example,

to search through unixpast.txt for the word “open”, type:

$ less unixpast.txt

Then, still in less, type / (slash) followed by the word to search:

/open

As you can see, less finds and highlights the keyword. Type n to search for the

next occurrence of the word.

head

The head command writes the first ten lines of a file to the screen.

First clear the screen then type:

$ head unixpast.txt

Then type:

$ head -5 unixpast.txt

What difference did the -5 do to the head command?

tail

The tail command writes the last ten lines of a file to the screen.

Clear the screen and type

$ tail unixpast.txt

Exercise

How can you view the last 15 lines of the file?

File and directory conventions

Unix allows any character except slash (/) and NULL (\000) to be part of a file or

directory name. The maximum length for a Unix file name is 255 bytes.

However, it is not a good idea to have unprintable characters in a file or directory

name. Some other characters that have special meanings such as / : * ? & $ should

be avoided unless you enjoy quoting them. Also, whitespaces within names are a

pain on the command line. The safest way to name a Unix file is to use only ASCII

alphanumeric characters, (letters and numbers), together with -

(hyphen), _ (underscore) and .(dot).

Bad filenames Good filenames Why bad?

notes-17/10/2012.txt notes-2012-10-17.txt contains special characters

load page.php load_page.php contains space

A valid file name usually starts with an ASCII-letter, digit, dot, or underscore, and

may end with a dot followed by a group of letters indicating the type of the file.

Files consisting of PHP code may for instance be named with the

ending .php (e.g. index.php). Unix does not normally care what file types you use

(some others programs may care), but following this convention let you use simple

commands such as ls *.php to list all PHP files in the current directory.

Directories and executable files (commands) are usually without a file type

extension.

In Unix, a directory is also a file. So the rules and conventions for files apply also

to directories.

File Permissions

File ownership is an important component of Unix that provides a secure method

for storing files. Every file in Unix has the following attributes −

Owner permissions − The owner's permissions determine what actions the

owner of the file can perform on the file.

Group permissions − The group's permissions determine what actions a

user, who is a member of the group that a file belongs to, can perform on the

file.

Other (world) permissions − The permissions for others indicate what

action all other users can perform on the file.

The Permission Indicators

While using ls -l command, it displays various information related to file

permission as follows −

$ls -l /home/amrood

-rwxr-xr-- 1 amrood users 1024 Nov 2 00:10 myfile

drwxr-xr--- 1 amrood users 1024 Nov 2 00:10 mydir

Here, the first column represents different access modes, i.e., the permission

associated with a file or a directory.

The permissions are broken into groups of threes, and each position in the group

denotes a specific permission, in this order: read (r), write (w), execute (x) −

The first three characters (2-4) represent the permissions for the file's owner.

For example, -rwxr-xr-- represents that the owner has read (r), write (w) and

execute (x) permission.

The second group of three characters (5-7) consists of the permissions for the

group to which the file belongs. For example, -rwxr-xr--represents that the

group has read (r) and execute (x) permission, but no write permission.

The last group of three characters (8-10) represents the permissions for

everyone else. For example, -rwxr-xr-- represents that there is read (r) only

permission.

File Access Modes

The permissions of a file are the first line of defense in the security of a Unix system.

The basic building blocks of Unix permissions are the read, write,

and execute permissions, which have been described below −

Read

Grants the capability to read, i.e., view the contents of the file.

Write

Grants the capability to modify, or remove the content of the file.

Execute

User with execute permissions can run a file as a program.

Directory Access Modes

Directory access modes are listed and organized in the same manner as any other

file. There are a few differences that need to be mentioned −

Read

Access to a directory means that the user can read the contents. The user can look

at the filenames inside the directory.

Write

Access means that the user can add or delete files from the directory.

Execute

Executing a directory doesn't really make sense, so think of this as a traverse

permission.

A user must have execute access to the bin directory in order to execute the ls or

the cd command.

Changing Permissions

To change the file or the directory permissions, you use the chmod (change mode)

command. There are two ways to use chmod — the symbolic mode and the absolute

mode.

Using chmod in Symbolic Mode

The easiest way for a beginner to modify file or directory permissions is to use the

symbolic mode. With symbolic permissions you can add, delete, or specify the

permission set you want by using the operators in the following table.

S.No. Chmod operator & Description

1 +

Adds the designated permission(s) to a file or directory.

2 -

Removes the designated permission(s) from a file or directory.

3 =

Sets the designated permission(s).

Here's an example using testfile. Running ls -1 on the testfile shows that the file's

permissions are as follows −

$ls -l testfile

-rwxrwxr-- 1 amrood users 1024 Nov 2 00:10 testfile

Then each example chmod command from the preceding table is run on the testfile,

followed by ls –l, so you can see the permission changes −

$chmod o+wx testfile

$ls -l testfile

-rwxrwxrwx 1 amrood users 1024 Nov 2 00:10 testfile

$chmod u-x testfile

$ls -l testfile

-rw-rwxrwx 1 amrood users 1024 Nov 2 00:10 testfile

$chmod g = rx testfile

$ls -l testfile

-rw-r-xrwx 1 amrood users 1024 Nov 2 00:10 testfile

Here's how you can combine these commands on a single line −

$chmod o+wx,u-x,g = rx testfile

$ls -l testfile

-rw-r-xrwx 1 amrood users 1024 Nov 2 00:10 testfile

Using chmod with Absolute Permissions

The second way to modify permissions with the chmod command is to use a number

to specify each set of permissions for the file.

Each permission is assigned a value, as the following table shows, and the total of

each set of permissions provides a number for that set.

Number Octal Permission Representation Ref

0 No permission ---

1 Execute permission --x

2 Write permission -w-

3 Execute and write permission: 1 (execute) + 2 (write) =

3

-wx

4 Read permission r--

5 Read and execute permission: 4 (read) + 1 (execute) =

5

r-x

6 Read and write permission: 4 (read) + 2 (write) = 6 rw-

7 All permissions: 4 (read) + 2 (write) + 1 (execute) = 7 rwx

Here's an example using the testfile. Running ls -1 on the testfile shows that the

file's permissions are as follows −

$ls -l testfile

-rwxrwxr-- 1 amrood users 1024 Nov 2 00:10 testfile

Then each example chmod command from the preceding table is run on the testfile,

followed by ls –l, so you can see the permission changes −

$ chmod 755 testfile

$ls -l testfile

-rwxr-xr-x 1 amrood users 1024 Nov 2 00:10 testfile

$chmod 743 testfile

$ls -l testfile

-rwxr---wx 1 amrood users 1024 Nov 2 00:10 testfile

$chmod 043 testfile

$ls -l testfile

----r---wx 1 amrood users 1024 Nov 2 00:10 testfile

Changing Owners and Groups

While creating an account on Unix, it assigns a owner ID and a group ID to each

user. All the permissions mentioned above are also assigned based on the Owner

and the Groups.

Two commands are available to change the owner and the group of files −

chown − The chown command stands for "change owner" and is used to

change the owner of a file.

chgrp − The chgrp command stands for "change group" and is used to

change the group of a file.

Changing Ownership

The chown command changes the ownership of a file. The basic syntax is as

follows −

$ chown user filelist

The value of the user can be either the name of a user on the system or the user id

(uid) of a user on the system.

The following example will help you understand the concept −

$ chown amrood testfile

$

Changes the owner of the given file to the user amrood.

NOTE − The super user, root, has the unrestricted capability to change the

ownership of any file but normal users can change the ownership of only those files

that they own.

Changing Group Ownership

The chgrp command changes the group ownership of a file. The basic syntax is as

follows −

$ chgrp group filelist

The value of group can be the name of a group on the system or the group ID

(GID) of a group on the system.

Following example helps you understand the concept −

$ chgrp special testfile

$

Changes the group of the given file to special group.

SUID and SGID File Permission

Often when a command is executed, it will have to be executed with special

privileges in order to accomplish its task.

As an example, when you change your password with the passwd command, your

new password is stored in the file /etc/shadow.

As a regular user, you do not have read or write access to this file for security

reasons, but when you change your password, you need to have the write permission

to this file. This means that the passwd program has to give you additional

permissions so that you can write to the file /etc/shadow.

Additional permissions are given to programs via a mechanism known as the Set

User ID (SUID) and Set Group ID (SGID) bits.

When you execute a program that has the SUID bit enabled, you inherit the

permissions of that program's owner. Programs that do not have the SUID bit set

are run with the permissions of the user who started the program.

This is the case with SGID as well. Normally, programs execute with your group

permissions, but instead your group will be changed just for this program to the

group owner of the program.

The SUID and SGID bits will appear as the letter "s" if the permission is available.

The SUID "s" bit will be located in the permission bits where the

owners’ execute permission normally resides.

For example, the command −

$ ls -l /usr/bin/passwd

-r-sr-xr-x 1 root bin 19031 Feb 7 13:47 /usr/bin/passwd*

$

Shows that the SUID bit is set and that the command is owned by the root. A capital

letter S in the execute position instead of a lowercase s indicates that the execute bit

is not set.

If the sticky bit is enabled on the directory, files can only be removed if you are one

of the following users −

The owner of the sticky directory

The owner of the file being removed

The super user, root

To set the SUID and SGID bits for any directory try the following command −

$ chmod ug+s dirname

$ ls -l

drwsr-sr-x 2 root root 4096 Jun 19 06:45 dirname

$

Introduction: Files and InodesIndex

In Unix/Linux, a file is a sequence of bytes without structure. Any necessary

structure (e.g. for a database) is added by the programs that manipulate the

data in the file. Linux itself doesn’t know about the internal structure of a

database file – all it does is return bytes.

1.1 Even hardware devices have file namesIndex

Unix/Linux tries its best to treat every device attached to it as if it were a list of

bytes. Therefore, everything, including network cards, hard drives, partitions,

keyboards, printers, and plain files are treated as file-like objects and each has

a name in the file system.

Your computer memory is /dev/mem.

Your first hard disk is /dev/sda.

A terminal (keyboard and screen) is /dev/tty1.

Etc.

$ ls -li /dev/mem /dev/sda /dev/tty1

5792 crw-r----- 1 root kmem 1, 1 Oct 13 02:30 /dev/mem

888 brw-rw---- 1 root disk 8, 0 Oct 13 02:30 /dev/sda

5808 crw-rw---- 1 root tty 4, 1 Oct 13 02:31 /dev/tty1

Most input and output devices and directories are treated as files in Linux. If

you have sufficient permissions, you can directly read all these devices using

their file system names. Recent versions of Unix/Linux have evolved

directories into non-readable (non-file) objects.

1.2 Index Nodes = InodesIndex

As with most things computer-related, things in the file system are not stored

by name, they are stored by number. Linux stores the data and information

about each disk object (e.g. a file or a directory) in a numbered data structure

called an “index node” or inode.

Each inode is identified by a unique inode number that can be shown using

the -i option to the lscommand:

$ ls -l -i /usr/bin/perl*

266327 -rwxr-xr-x 2 root root 10376 Mar 18 2013 /usr/bin/perl

266327 -rwxr-xr-x 2 root root 10376 Mar 18 2013 /usr/bin/perl5.14.2

266331 -rwxr-xr-x 2 root root 45183 Mar 18 2013 /usr/bin/perlbug

266328 -rwxr-xr-x 1 root root 224 Mar 18 2013 /usr/bin/perldoc

266329 -rwxr-xr-x 1 root root 125 Mar 18 2013 /usr/bin/perldoc.stub

266330 -rwxr-xr-x 1 root root 12318 Mar 18 2013 /usr/bin/perlivp

266331 -rwxr-xr-x 2 root root 45183 Mar 18 2013 /usr/bin/perlthanks

The program /usr/bin/perl, above, is not stored on disk with its name perl; it

is stored somewhere else, under inode number 266327.

Unix/Linux directories are what map file system names (e.g. perl) to inode

numbers (e.g. 266327). In the example above, you can see that

file /usr/bin/perl is really inode number 266327 (and that another

name perl5.14.2 leads to the same inode!). When you access the perl program,

the system finds the perl name in a directory, paired with the inode

number 266327 that holds the actual data, and then the system has to go

elsewhere on disk to that inode number to access the data for the perl program.

File data is stored under inode numbers, not under names.

Every file has its name entered in a directory and is assigned a unique inode

number. Each file name can be mapped to only one single inode number, but

one inode number may have many names (as is the case with perl, above).

Inode numbers are specific to a file system inside a disk partition. Every file

on a file system (in that partition) has a unique inode number. Numbering is

done separately for each file system, so different disk partitions may have file

system objects with the same inode numbers.

Every Linux file system is created new with a large set of available inodes.

You can list the free inodes using df -i. Older types of file systems can never

make more inodes, even if there is lots of disk space available; when all the

inodes are used up, the file system can create no more files until some files are

deleted to free some inodes.

2 File System DiagramsIndex

Most diagrams showing file systems and links in Unix texts are wrong and

range from confusing to seriously misleading. Here’s the truth, complete with

an ASCII-art file system diagram below.

Names for inodes (names for files, directories, devices, etc.) are stored on disk

in directories. Only the names and the associated inode numbers are stored in

the directory; the actual disk space for whatever data is being named is stored

in the inode, not in the directory. The names and numbers are kept in the

directory; the names are not kept with the data.

In the directory, beside each name, is the index number (inode number)

indicating where to find the disk space used to actually store the thing being

named. You can see this name-inode pairing using ls -i:

$ ls -i /usr/bin/perl*

266327 /usr/bin/perl 266329 /usr/bin/perldoc.stub

266327 /usr/bin/perl5.14.2 266330 /usr/bin/perlivp

266331 /usr/bin/perlbug 266331 /usr/bin/perlthanks

266328 /usr/bin/perldoc

The crucial thing to know is that the names and the actual storage for the

things being named are in separate places. Most texts make the error of

writing Unix file system diagrams that put the names right on the things that

are being named. That is misleading and the cause of many misunderstandings

about Unix/Linux files and directories. Names exist one level above (separate

from) the items that they name:

WRONG - names on things RIGHT - names above things

======================= ==========================

R O O T ---> [etc,bin,home] <-- ROOT directory

/ | \ / | \

etc bin home ---> [passwd] [ls,rm] [abcd0001]

| / \ \ | / \ |

| ls rm abcd0001 ---> | <data> <data> [.bashrc]

| | | |

passwd .bashrc ---> <data> <data>

Directories are lists of names and numbers, as shown by the square-bracketed

lists in the diagram on the right, above. (The actual inode numbers are omitted

from this small diagram.) The name of each thing (file, directory, special file,

etc.) is kept in a directory, separate from the storage space for the thing it

names. This allows inodes to have multiple names and names in multiple

directories; all the names can refer to the same storage space by using the same

inode number.

In the correct diagram on the right, the directories give names to the objects

below them in the tree. The top directory on the right is the ROOT directory

inode, containing the list of names etc, bin, and home (and others). Because

there is no name level above the ROOT directory to give it a name, the ROOT

directory has no name!

The line leading downwards from the name bin in the ROOT directory

indicates that the name bin is paired with an inode number that is another

directory inode containing the list of names in the bindirectory, including

names ls and rm (and others). The line leading down from ls in

the bin directory inode leads to the data inode for the file /bin/ls. There is no

name kept with the data inode – the name is up in the directory above it.

The ROOT inode has no name because there is no directory above it to give it

one! Every other directory has a name because there is a directory inode above

it that contains its name.

3 Inodes manage disk blocksIndex

The actual data for each Unix file or directory stored on disk is managed by

numbered on-disk data structures called “inodes” (index nodes). One inode is

allocated for each file and each directory. Unix inodes have unique numbers,

not names, and it is these numbers that are kept in directories alongside the

names. The -i option to ls shows these inode numbers.

A Unix inode manages the disk storage space for a file or a directory. The

inode contains a list of pointers to the disk blocks that belong to that file or

directory. The larger the file or directory, the more disk block pointers it needs

in the inode. Also stored in the inode are the attributes of the file or directory

(permissions, owner, group, size, access/modify times, etc.); but, not the name

of the file or directory. Inodes have only numbers, attributes, and disk blocks –

not names. The names are kept separately, in directories.

Everything in a Unix file system has a unique inode number that manages the

storage for that thing: every file, directory, special file, etc. Files and

directories are both managed with inodes.

4 Directory inodes hold all the namesIndex

File system names are stored in directory inodes. The names are not kept in the

same inodes with the things that they name. The name of a file or directory is

not kept in the inode with the file attributes or pointers to disk blocks; the

name is kept in a directory somewhere else.

Directories are what give names to inodes on Unix. Directories can be thought

of as “files containing lists of names and inode numbers”. Files have disk

blocks containing file data; directories also have disk blocks; but, the blocks

contain lists of names and inode numbers.

Like most other inodes, directory inodes contain attribute information about

the inode (permissions, owner, etc.) and one or more disk block pointers in

which to store data; but, what is stored in the disk blocks of a directory is not

file data but directory data (names and inode numbers).

A Unix directory is simply a list of pairs of names and associated inode

numbers. That is all – the disk blocks of Unix directories contain only names

and inode numbers. The rest of the attribute information about an item named

in a directory (the type, permissions, owner, etc.) is kept with the inode

associated with the name. You must use the inode number from the directory

to find the inode on disk to read its attribute information; reading the directory

only tells you the name and inode number. (Some modern Unix/Linux file

systems also cache a second copy of the inode type in the directory to speed up

common file system browsing operations.)

Reading a Unix directory tells you only some names and inode numbers; you

know nothing about the types, sizes, owners, or modify times of those inodes

unless you actually go out to the separate inode on disk and access them to

read the attributes. Without actually accessing the inode, you can’t know most

of the attributes of the file system object; you can’t even know if the inode is a

file inode or a directory inode.

To find out attribute information of some file system object, which is stored

with the inode, not in the directory, you must first use the inode number

associated with the object to find the inode of the item and look at the item’s

attributes. This is why ls or ls -i are much faster than ls -l:

a. ls or ls -i only need to read the names and inode numbers from the directory – no

additional inode access is needed because no other attributes are being queried.

Reading the one directory inode is sufficient.

b. ls -l has to display attribute information, so it has to do a separate inode lookup to

find out the inode attribute information for every inode in the directory. A

directory with 100 names in it requires 100 separate inode lookups to fetch the

attributes.

No attribute information about the things named in the directory is kept in the

directory (except on those modern file systems where caching is enabled). The

directory only contains pairs of names and inode numbers.

To find a thing by name, the system goes to a directory inode, looks up the

name in the disk space allocated to that directory, finds the inode number

associated with the name, then goes out to the disk a second time and finds

that inode on the disk. If that inode is another directory, the process repeats

from left-to-right along the pathname until the inode of the last pathname

component (on the far right in the pathname) is found. Then the disk block

pointers of that last inode can be used to find the data contents of the last

pathname component.

(The storage for each directory is itself managed by an inode, so the inode for

the directory itself contains attribute information about the directory, not about

the things named in the directory. Use ls -ld to see the attributes of the

directory inode itself.)

4.1 Damaged directories create orphansIndex

The name and inode number pairing in a Unix directory is the only connection

between a name and the thing it names on disk. The name is kept separate

from the data belonging to the thing it names (the actual inode on disk). If a

disk error damages a directory inode or the directory disk blocks, file data is

not usually lost; since, the actual data for the things named in the directory are

stored in inodes separate from the directory itself. If a directory is damaged,

only the names of the things are lost and the inodes become “orphan” inodes

without names. The storage used for the things themselves is elsewhere on

disk and may be undamaged. You can run a file system recovery program such

as fsck to recover the data (but not the names).

The name of an item (file, directory, etc.) and its inode number are kept in a

directory. The directory storage for that name and number is managed by its

own inode that is separate from the inode of each thing in the directory. The

name and number are stored in the directory inode; the data for the item named

is stored in its own inode somewhere else.

5 Multiple names – hard linksIndex

Because (1) a file is managed by an inode with a unique number, (2) the name

of the file is not kept in that inode, and (3) directories pair names with inode

numbers, a Unix file (inode) can be given multiple names by having multiple

name-and-inode pairs in one or more directories.

Inode 123 may be paired with the name cat in one directory and the same 123

may be paired with the name dog in the same or a different directory. Either

name leads to the same 123 file inode and the same data and attributes.

Though there appear to be two different files cat and dog in the directory, the

only thing different between the two is the name – both names lead to the same

inode and therefore to the same data and attributes (permissions, owner, etc.).

5.1 Link counts count names; ln creates, rm removes only a nameIndex

Multiple names for the same inode are called “hard links”. The ln command

can create a new name (a new hard link) in a directory for an existing inode.

The system keeps a “link count” in each inode that counts the number of

names each inode has been given. The rm command removes a name (a hard

link) from a directory, decreasing the link count. When the link count for an

inode goes to zero, the inode has no names and the inode is recycled and all

the storage and data used by the item is released.

The rm command does not remove files; it removes names for files. When all

the names are gone, the system removes the file and releases the space.

6 Tracing Inodes in PathnamesIndex

When you look at a Unix pathname, remember that that the slashes separate

names of pathname components. All the components to the left of the

rightmost slash must be directories, including the “empty” ROOT directory

name to the left of the leftmost slash. For example:

/home/alex/foobar

In the above example, there are three slashes and therefore four pathname

components. The “empty” name in front of the first slash is the name of the

ROOT directory. The ROOT directory doesn’t have a name. (Some books get

around this by calling the ROOT directory “slash” or /. That is wrong. ROOT

doesn’t have a name – slashes separate names.)

1. Inside the ROOT directory is the name of the home directory.

2. Inside the home directory is the name of the alex directory.

3. Inside the alex directory is the name of the foobar file.

The last (rightmost) component of a pathname can be a file or a directory (or

other); for this example, let’s assume foobar is a file name.

Below is a file system diagram written correctly, with the names for things

shown one level above the things to which the names actually refer. Each box

represents an inode; the inode numbers for the box are given beside the box,

on the left. Inside the directory inodes you can see the pairing of names and

inode numbers. (These inode numbers are made up – see your actual Unix

system for the real inode numbers.) One of the inodes, #12, is not a directory;

it is an inode for a file and contains the file data. The downward arrows trace

two paths (hard links) to the same #12 file

data, /home/alex/foobar and /home/alex/literature/barfoo:

We will trace the inodes for two pathnames in the diagram below:

1. /home/alex/foobar

2. /home/alex/literature/barfoo

Follow the downward-pointing arrows:

+----+-----+-----------------------------------------+

#2 |. 2 |.. 2 | home 5 | usr 9 | tmp 11 | etc 23 | ... |

+----+-----+-----------------------------------------+

| The inode #2 above is the ROOT directory. It has the

| name "home" in it. The *directory* "home" is not

| here; only the *name* is here. The ROOT directory

| itself does not have a name!

V

+----+-----+---------------------------------------------------+

#5 |. 5 |.. 2 | alex 31 | leslie 36 | pat 39 | abcd0001 21 | ... |

+----+-----+---------------------------------------------------+

| The inode #5 above is the "home" directory. The name

| "home" isn't here; it's up in the ROOT directory,

| above. This directory has the name "alex" in it.

V

+----+-----+---------------------------------------------------+

#31 |. 31|.. 5 | foobar 12 | temp 15 | literature 7 | demo 6 | ... |

+----+-----+---------------------------------------------------+

| The inode #31 above is |

| the "alex" directory. The |

| name "alex" isn't here; |

| it's up in the "home" |

| directory, above. This |

| directory has the names |

| "foobar" and "literature" |

| in it. |

| V

+----+-----+--|-------------------------------------------+

#7 |. 7 |.. 31| | barfoo 12 | morestuf 123 | junk 99 | ... |

+----+-----+--|-------------------------------------------+

| | The inode #7 above is the "literature" directory.

| | The name "literature" isn't here; it's up

| | in the "alex" directory. This directory has

| | the name "barfoo" in it.

| |

V V

*-----------* This inode #12 on the left is a file inode.

| file data | It contains the data blocks for the file.

#12 | file data | This file happens to have two names, "foobar"

| file data | and "barfoo", but those names are not here.

*-----------* The names of this file are up in the two

directories that point to this file, above.

The pathname /home/alex/foobar starts at the nameless ROOT directory,

inode #2. It travels through two more directory inodes and stops at file

inode #12. Using all four inode numbers, /home/alex/foobar could be written

as #2->#5->#31->#12.

The pathname /home/alex/literature/barfoo starts at the ROOT inode and

travels through three more directory inodes. It stops at the same #12 file inode

as /home/alex/foobar. Using all five inode

numbers, /home/alex/literature/barfoo could be written as #2->#5->#31->#7-

>#12.

Thus, /home/alex/foobar and /home/alex/literature/barfoo are two

pathnames leading to the same inode #12file data. The

names foobar and barfoo are two names for the same file and are called “hard

links”.

7 Tracing Pathname 1: /home/alex/foobarIndex

Let’s examine each of the above inodes.

The box below represents the layout of names and inode numbers inside the

actual disk space given to the nameless ROOT directory, inode #2:

+----+-----+-----------------------------------------+

#2 |. 2 |.. 2 | home 5 | usr 9 | tmp 11 | etc 23 | ... |

+----+-----+-----------------------------------------+

The above ROOT directory has the name home in it, paired with inode #5. The

actual disk space of the directory home is not here; only the name home is

here, alongside of its own inode number #5. To read the actual contents of

the home directory, you have to find the disk space managed by

inode #5somewhere else on disk and look there.

The above ROOT directory pairing of home with inode #5 is what gives

the home directory its name. The name home is separate from the disk space

for home. The ROOT directory itself does not have a name; because, it has no

parent directory to give it a name!

The ROOT directory is the only directory that is its own parent. If you look at

the ROOT directory above, you will see that both the name . and the name .. in

this ROOT directory are paired with inode #2, the inode number of the ROOT

directory. Following either name . or .. will lead to inode #2 and right back to

this same ROOT inode.

Let us move to the storage space for the home directory at inode #5.

The box below represents the layout of names and inode numbers inside the

actual disk space given to the home directory, inode #5:

+----+-----+---------------------------------------------------+

#5 |. 5 |.. 2 | alex 31 | leslie 36 | pat 39 | abcd0001 21 | ... |

+----+-----+---------------------------------------------------+

The name home for this inode isn’t in this inode; the name home is up in the

ROOT directory. This homedirectory has the name alex in it, paired with

inode #31. The directory alex is not here; only the name alex is here. To read

the alex directory, you have to find inode #31 on disk and look there. (In fact,

until you look up inode #31 and find out that it is a directory, you have no way

of even knowing that the name alex is a name of a directory!)

Let us move to the storage space for the alex directory at inode #31.

The box below represents the layout of names and inode numbers inside the

actual disk space given to the alex directory, inode #31:

+----+-----+---------------------------------------------------+

#31 |. 31|.. 5 | foobar 12 | temp 15 | literature 7 | demo 6 | ... |

+----+-----+---------------------------------------------------+

The name alex for this inode isn’t in this inode; the name alex is up in

the home directory. This alexdirectory has the name foobar in it, paired with

inode #12. The file foobar is not here; only the name foobar is here. To read

the data from file foobar, you have to find inode #12 on disk and look there.

(In fact, until you look up inode #12 and find out that it is a plain file, you

have no way of even knowing that the name foobar is a name of a plain file!)

Let us move to the storage space for the foobar file at inode #12.

The box below represents the actual disk space given to the foobar file,

inode #12:

*-----------*

#12 | file data |

*-----------*

The name foobar for this inode isn’t in this inode; the name foobar is up in

the alex directory. This foobarinode is a file inode, not a directory inode, and

the attributes of this inode will indicate that.

The inode for a file contains pointers to disk blocks that contain file data, not

directory data. There are no special directory names . and .. in files. There are

no names here at all; the disk block pointers in this inode point to just file data

(whatever is in the file).

This completes the inode trace for /home/alex/foobar: #2->#5->#31->#12

8 Tracing Pathname 2: /home/alex/literature/barfooIndex

Let’s now trace the inode path for the name /home/alex/literature/barfoo.

This pathname is a “hard link” to /home/alex/foobar; both

the foobar and barfoo names point to the same inode number. Let’s see how:

The trace from ROOT through /home/alex is the same as before. Things

change in our second trace because of /home/alex/literature. If we look at

the alex directory inode #31 we see that the name literature is paired with

inode #7:

+----+-----+---------------------------------------------------+

#31 |. 31|.. 5 | foobar 12 | temp 15 | literature 7 | demo 6 | ... |

+----+-----+---------------------------------------------------+

The alex directory inode #31 above says to follow the trail to

the literature name we must go to inode #7. (We won’t know whether

the #7 inode for literature is a file or a directory until we get there!)

The box below represents the layout of names and inode numbers inside the

actual disk space given to the literature directory, inode #7, which turns out to

be a directory:

+----+-----+---------------------------------------------+

#7 |. 7 |.. 31| barfoo 12 | morestuf 123 | junk 99 | ... |

+----+-----+---------------------------------------------+

The name literature for this inode isn’t in this inode; the name literature is up

in the alex directory inode #31. This literature directory inode #7 has the

name barfoo in it, paired with inode #12. The actual data for the thing that

is barfoo is not here; only the name barfoo is here. You will recall that we

have seen inode #12 in the previous trace.

Above, in the alex directory (inode #31), inode #12 was also paired with the

name foobar. In the literature directory (inode #7), inode #12 is paired with

the name barfoo. Inode #12 has two different names;

names foobar and barfoo are both hard links to the same inode #12:

$ ls -i /home/alex/foobar /home/alex/literature/barfoo

12 /home/alex/foobar 12 /home/alex/literature/barfoo

Two names means the “link count” of inode #12 is set to “two”. Both names

lead to the same #12 inode and thus to the same data and same attributes. This

is one single file with two names. A change to the file data using the

name foobar changes the data in inode #12. That changes file data for the

name barfoo too; because, foobar and barfoo are two names for the

same #12 inode storage – they are two names that point to the same storage

inode.

Everything about data inode #12 except its name is kept with the inode. The

only thing different in a long listing of foobar and barfoo will be the names;

everything else (file type, permissions, owner, group, link count, size,

modification times, etc.) is part of inode #12 and must therefore be identical

for the two names. Neither name is more “original” than the other; both names

have equal status. To release the #12 inode storage, you have to delete both

names (so the link count drops to zero).

9 Path TraversalIndex

Let’s use the above inode data to follow a valid path such as:

/home/alex/literature/barfoo

Start on the left and walk the tree to the right. To be a valid Unix path,

everything to the left of the rightmost slash must be a directory. (Thus,

ROOT, home, alex, and literature must be directories, if this is a valid

pathname.)

Start with the nameless ROOT directory in front of the first slash (ROOT

doesn’t have a name, since it does not appear in any parent directory) and look

for the first pathname component (home) inside that directory (inside

inode #2).

Let’s trace the pathname:

Look in the ROOT directory (located in inode #2) for the name of the first

pathname component: home. We find the name home inside the ROOT

directory, paired with inode #5. Go back out to the disk to find inode #5 that is

the actual home directory.

Note how the names are separate from the things they name. The actual directory

inode #5 of the home directory is not the same as the inode #2 of the ROOT

directory that contains the directory name home. The name is stored in a different place (#2) than the thing it names (#5).

In inode #5, the directory that has the name home, look for the name alex. We

find alex paired with inode #31. Go back out to the disk to find inode #31 that

is the actual alex directory. Again, the name alex is contained in directory

inode #5 (home) and that name is stored separately from inode #31 that is the

actual alex directory.

In inode #31, the directory that has the name alex, look for the

name literature. We find literaturepaired with inode #7. Go back out to the

disk to find inode #7 that is the actual literature directory. Again, the

name literature is contained in directory inode #31 (alex) and that name is

stored separately from the inode #7 that is the actual literature directory.

In inode #7, the directory that has the name literature, look for the

name barfoo. We find it paired with inode #12. Go back out to the disk to find

inode #12 that is the actual data of the file barfoo. Again, the name barfoo is

contained in directory inode #7 (literature) and that name is stored separately

from the inode #12 that is the actual data of the file. The name of a file is not

part of the inode that makes up the actual file data.

9.1 Permissions on data vs. permissions on directoriesIndex

You now have found the disk node (inode) that is your file data: inode #12.

The name of this file, barfoo, is stored up in inode #7 that is

the literature directory. The name is separate from the data it names.

If file data inode #12 has appropriate permission attributes, you can read or

write the data in the file. It is the permission attributes on the inode containing

the file data that govern what you can do with the data. The permissions on

the inode of the directory containing the name of the file (directory inode #7)

don’t control what you can do with the data of the file.

If the any of the inodes of the directories leading down to the file

inode #12 don’t give you search permission, you won’t be able to reach the

file’s data inode that way and won’t be able to access the file’s data using

those directories; but, perhaps some other directories may lead you to the same

inode #12, if the file has another name.

To access and read the data in a file path such as:

/home/alex/literature/barfoo

you need appropriate search permissions on the ROOT directory inode,

the home directory inode, the alexdirectory inode, the literature directory

inode, and finally read permissions on the barfoo file data inode #12.

It is the barfoo file data inode #12 permissions that determine whether or not

you can read or change the data of the file. Reading or changing the data in the

file requires permissions on the inode #12 that contains the data blocks of the

file itself.

It is the literature directory inode permissions (inode #7) that determine what

you can do with the nameof the file, because the literature directory

(inode #7) is where the name barfoo is kept. Changing, linking to, or

removing the name of a file operates on the inode of the directory in which the

file name appears; altering the name has nothing to do with reading or

changing the inode that contains the data blocks of the file itself.

You can have no permissions on the inode that contains the data blocks of the

file itself (it may even be owned by some other user) and still you may be able

to rename or remove the name of the file from a directory on whose inode you

do have permissions. The name(s) of a file is(are) stored in separate inodes

from the data blocks of the file.

Names are separate from the things that they name. The permissions of the

names are also separate from the permissions of the data.

Changing a name only requires write/execute permissions on a directory. No

permissions are needed on the inode of the thing being renamed. Changing

the content of a file only requires write permissions on the data inode of

the file itself, not on the directory that holds the name of the file.

10 Links and Directories

Normally when you do ls -l dir you see the permissions of the contents of the

directory, not the directory itself. What command and options are needed to see

the access permissions and link count of a directory, instead of the contents of a

directory? (RTFM)

When you are inside a directory, what is the name you use to refer to the directory

itself? (This name works inside any directory.) What name always refers to the

unique parent directory?

How many links (names) does a brand new, empty directory have? Why isn’t it

just one link, as it is for a new file? (In other words, why does a new file have one

link and a new directory have more than that?)

Why does creating a sub-directory in a directory cause the directory’s link (name)

count to increase by one for every sub-directory created? (Recall that a link count

is a count of names.)

Why doesn’t the link (name) count of the directory increase when you create files

in the directory?

Give the Unix command and its output that shows the inode number and owners

of the following directories:

a. your current directory

b. your parent directory

c. your HOME directory

d. the directory named /home

e. the ROOT directory

f. the directory named /root

Note: Show only one line of output for each single directory; do not show the

contents of the directory. Use a command (and options) that will show only the

directory itself, not its contents. (RTFM)