Tuesday, July 16, 2019

Unix File Tree Part-1




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
  • Meta files --> /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 suggest giving priority to defined convention over 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
  • Meta files --> /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: https://freestocks.org/fs/wp-content/uploads/2016/04/tree_trunk.jpg



4 comments:

Docker-Compose As A Bundled Application

When docker came to market as a virtualization tool, it blew the market out of proportion. With its lightweight images, multi-os suppor...