Main Body

1 The Hierarchical File System

Pre-amble

Unix is primarily a command line oriented operating system.  Most commands are an action which is performed on an object, typically a file or directory.  In order to be productive in a Unix environment, one must be intimately familiar with the concept of the hierarchical file system.  Mastering this concept is fundamental to successful work in a Unix environment and is the key takeaway of this section.

Hierarchical File System

The Unix file system is that of an inverted tree.  Imagine a tree with leaves and branches but turned upside down with the root or main trunk at the top.  The main trunk branches off to smaller branches and eventually leaves.  By analogy, the root directory typically contains several directories (folders) which in turn contain other directories (subdirectories) and/or files.  Just as a tree branch can have smaller branches or leaves, a leaf cannot have other branches or leaves.  Similarly, the difference between a directory and a file is that a directory can contain other directories or files, but a file cannot contain other directories or files — a file is a terminal node.

The figure below shows the typical layout of a Unix file system.  While systems vary greatly in size, most will have at least these directories.  The convention in this diagram uses an ellipse to depict a directory and a rectangle to depict a file.

Ellipse containing / at top, 4 ellipses connected with lines beneath top ellipse containing words etc, bin, dev, users. Rectangles beneath ellipses represent files.
Typical hierarchical file structure of a Unix system

 

Explanation of common subdirectories:

Directory

Remarks

etc contains operation and administrative files
bin contains executable commands
dev contains the devices connected to the system (printers, terminals, etc…); these devices still appear as files
users* contains user files and directories. *The directory name is not standard and varies between systems.  Other common variations are things like “home”.  Some larger systems will even have more than one top-level user directories such as “faculty”, “staff”, “classof31”, etc.

How to Specify a File or Directory in Unix

As most Unix commands act on files or directories, it is necessary to be able to specify such an entity.

There are two methods to specify a file or directory, absolute and relative:

Absolute

To specify a file or directory using the absolute method, start with the root directory (/) and write each directory that is encountered on the path to the directory or file being specified.  Separate each directory with a “/” forward slash character.

Examples

Specify the etc directory in the above system.
/etc
Specify the file named passwd in the above system.
/etc/passwd
Specify the file named ls in the above system.
/bin/ls
Specify the file named mydata in the above system.
/users/raj/work/mydata

 

Key Takeaways

The absolute specification always starts with a “/” (forward slash).

 

Relative

When working on Unix, the user will always “be” at some logical position within the hierarchy.  This position is termed the “current working directory” or simply the “current directory”. The specification of a relative path is relative to this current directory position.  Note that it is possible to change one’s current directory while working; this will be discussed in a later chapter.

To specify a file or directory using the relative method, start with the current directory and write each directory that is encountered on the path to the directory or file being specified.  Separate each directory with a “/” forward slash character.

Examples

Specify the file mydata with current directory: /users/raj/

work/mydata

Specify the file mydata with current directory: /users/raj/work/

mydata

Specify the file report with current directory: /users/raj/work

../report

As the file report is not contained in the current directory, it is necessary to go up one level first (to raj) to be able to reach the file report.  Here the double dots mean “parent directory” or one level up.

 

Key Takeaways

The relative specification never starts with a “/” (forward slash).

 

When should one use absolute vs. relative specifications?  In many cases both are acceptable.  One may notice that a relative specification usually requires less typing.  Who likes more typing? An absolute path is preferred when the user or programmer values portability allowing the specification to be used from any position on the system by any user.

Points to Consider

  • Names for files and directories are case-sensitive.  Thus report, Report, and REPORT are all distinct.
  • Names may include any letters, digits, and some special characters (period, comma, underscore, etc.) but not /, <, >, &, :, |.
  • Names may be up to 255 characters in length.
  • There is no requirement for file extensions (few characters after a period).  All of the following are valid names:
    • report
    • letter_to_bob.text
    • forecast.July,Version1
    • notes.doc
  • Names must be unique within a directory (no duplicates allowed).  This is automatically enforced by the operating system.  In the raj directory, it would not be possible to create another file or directory called work.  Consider the analogy of human families:  Two siblings would not share the same name, but a cousin, uncle, or grandparent could share the same name without conflict.

Home Directory

The home directory is a private area for the user files and directories. Each user will have a directory name matching the login name assigned by the system administrator.

While it is correct and possible to specify a home directory using the absolute and relative methods aforementioned, there exists an abbreviation consisting of a ~ (tilde) followed by the user’s login name.  Advantage: This avoids having to know the name of the user file area which is non-standard:  some installations call it users, others call it home, still others have their own conventions.  

Examples

Eg. Raj’s home directory would be

~raj

Eg. A file in his directory would be

~raj/report

 

 

License

Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Productivity in Common Operating Systems Copyright © 2022 by Lester Hiraki is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.

Share This Book