Unix File Tree Part-1

Sudipt Sharma
Opstree
Published in
3 min readJul 17, 2019

The Philosophy of Unix directory structure

Imitating file tree literally with tree

Nature has its own way to reach out for perfection and the same should be our instinct to make our creations perfect.

Dennis Ritchie, father of Unix and an esteemed computer scientist might have implied the same approach for Unix directory structure.

Why?

Before getting into the hierarchy of Unix File Tree lets discuss why we need it. The need for a directory structure arises when multiple users are handling multiple software along with their dependent files. Let me explain this with a couple of scenarios.

Scenario-1:

Consider an ideal software or package which requires multiple files to function properly.

  • Binary files
  • Configuration files
  • Log files
  • Data files
  • Metadata files during execution
  • Libraries

For now, let’s consider there is just one directory and I am keeping all of the dependent files in that directory.

$ ls
package-1.binary package-1.conf package-1.data package-1.lib package-1.log package-1.tmp

Another software comes in the picture which has its own dependent files.

$ ls
package-1.binary package-1.data package-1.log package-2.binary package-2.data package-2.log
package-1.conf package-1.lib package-1.tmp package-2.conf package-2.lib package-2.tmp

Things will get messy while dealing with various software since handling them won’t be easy and will lead to a chaotic situation.

Scenario-2:

Suppose I am a system admin and managing all of the software in the above scenario-1. To make things organized I created different directories to place the dependent files.

  • Binary files → /dir-1
  • Configuration files → /dir-2
  • Log files → /dir-3
  • Data files → /dir-4
  • Metafiles → /dir-5
  • Libraries → /dir-6

As the work gets overloaded I need more admins to support they won’t be able to relate with the naming convention as I did.

To escape this situation the creator of Unix decided to follow a philosophy “Convention over Configuration”.

As the name suggests giving priority to defined convention over the individual’s configuration. So that everyone should be on the same page and keeping that in mind everyone else will follow.

And the simulation of the philosophy was like this

  • Binary files → /bin
  • Configuration files → /etc
  • Log files → /log
  • Data files → /var
  • Metafiles → /tmp
  • Libraries → /lib

Which resulted in the Unix File Tree

$ tree -d -L 1
.
├── apps
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── lib64
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── snap
├── srv
├── sys
├── tmp
├── usr
└── var
22 directories

You might be thinking that how will Unix figure out where is the configuration file, where is the binary and rest of the stuff of the software.

Here comes the role of the PATH variable

$ echo $PATH
/home/dennis/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

These are environment variables specifying a set of directories where executable programs are located. In general, each executing process or user session has its own PATH setting.

So now we have a proper understanding of why do we need a File Tree.

For diving deep into the significance of each one of the directory stay tuned for Unix File Tree Part-2.

Cheers!

Image Source: http://betterlemonade.com/wp-content/uploads/2019/02/green-nature-tree-91153.jpg

--

--