Linux basics
Command-line interface (part 6)
File hierarchy
The newbies to the Linux command-line may wind up asking why there are such a significant number of special directories, what they are there for, and why things are sorted out how they are. If you are not acclimated with how Linux arranges documents, the directories can appear to be absolute self-assertive with odd truncated names and, much of the time, repetitive names. It turns out there’s a strategy to this depends on many years of UNIX convention, and in this section, we will be giving a prologue to the Linux directory structure.
- “/root “: The “/root” registry is a unique home index for the root user on the framework. It’s usable and readable only by the root client, and it’s generally structured to work much like a “/home” directory yet for records and settings the root client needs. Nowadays, numerous frameworks impair the root client for utilizing the “sudo” command to get super-user benefits, so this registry isn’t used so much.
Ex: (kali@kali:~$ cd /root)
- “/bin” and “/sbin”: These registries store binary executable records, which are fundamental for booting the system. The significant contrast between these directories is that the “/sbin” registry is proposed for system binaries that administrators will use to manage the Linux operating framework.
Ex: (kali@kali:~$ cd /bin)
- “/lib”: This directory stores the shared libraries for the binaries found in the “/bin” and “/sbin” directories.
Ex: (kali@kali:~$ cd /lib)
- “/boot”: The purpose of this index is to store all the bootloader documents, kernel records, and “initrd” files. It’s frequently treated as a different, small partition so that the bootloader can peruse it more effectively.
Ex: (kali@kali:~$ cd /boot)
- “/opt”: The idea of the “/opt” directory is to store optional software, downloaded from outside the Linux repository. You can find an empty “/opt” folder on many Linux-like systems.
Ex: (kali@kali:~$ cd /opt)
- “/etc”: The “/etc” directory stores system setup files. In the event that you have to configure a service on a Linux framework, or change network or other core settings, this is the place to look first.
Ex: (kali@kali:~$ cd /etc)
- “/home”: The “/home” directory is the area on Linux frameworks where each user stores his/her records. Every directory under “/home” is named after a specific user name and is owned by that user.
Ex: (kali@kali:~$ cd /home)
- “/srv”: The purpose of this directory is to store documents that a server may share remotely.
Ex: (kali@kali:~$ cd /srv)
- “/media” and “/mnt”: When you add extra filesystems to your PC, regardless of whether it’s from a USB drive, an NFS mount, or different sources, you need some standard place to mount them. For this reason, we use “/mnt” and “/media” directories. The “/media” register fills in as a mount point for removable media gadgets, for example, CDROMs, computerized cameras, and different USB-connected devices. Since “/media” is relatively new in the UNIX world, you could experience frameworks running without this registry. The “/mnt” directory should be empty and only used for temporary mount points.
Ex: (kali@kali:~$ cd /media)
- “/usr”: Although “/usr” is articulated like a user, we need to know that it represents Unix System Resources. The “/usr” directory ought to contain shareable, read-only information.
Ex: (kali@kali:~$ cd /usr)
“/usr/bin”: This directory incorporates a lot of commands.
Ex: (kali@kali:/usr$ cd /usr/bin/)
“/usr/lib”: this directory contains libraries that are not legitimately executed by clients or scripts.
Ex: (kali@kali:/usr$ cd /usr/lib)
“/usr/local”: This registry can be utilized by an owner to install software locally.
Ex: (kali@kali:/usr$ cd /usr/local/)
“/usr/share”: This directory contains architecture-independent data.
Ex: (kali@kali:/usr$ cd /usr/share)
“/usr/src”: This directory is for kernel source files.
Ex: (kali@kali:/usr$ cd /usr/src)
- “/dev”: You will discover device records here. UNIX frameworks have an “everything is a document” rule that implies even your equipment ends up with a file. This catalog contains records for gadgets on your system from disks and partitions to mice and keyboards.
Ex: (kali@kali:~$ cd /dev)
- “/proc”: The “/proc” registry stores records that represent data about pretty much the majority of the running processes on the framework.
Ex: (kali@kali:~$ cd /proc)
- “/sys”: While some kernel state documents have appeared in “/proc,” nowadays, they are supposed to be put away in “/sys.” The “/sys” registry is intended to contain these documents that let you collaborate with the kernel, and this catalog gets powerfully populated with records that frequently appear as nested series of recursive symlinks.
Ex: (kali@kali:~$ cd /sys)
- “tmp”: Applications and users should utilize “/tmp” to store impermanent information when required. Information stored in “/tmp” may use either disk space or RAM. The two of which are overseen by the operating system. Never use “/tmp” to store information that is significant or which you wish to archive.
Ex: (kali@kali:~$ cd /tmp)
