CLI for noobies: man for hier

This is the third in a series of articles on the Linux CLI for Noobies. The last time the topic was files. This is more of the same, except that we are stepping back a pace or two for a broader look. We’ll cover where certain types of files are typically kept in Linux distributions. That’s where using the man command for “hier” comes into play: it covers the complete file system hierarchy. We’ll also spend a little bit of time on how to find or locate that one particular file on your system that you need in order to whatever. So let go of Mama Gui’s hand, you wanna-be dweebs, and follow me.

Where things go on your system is important. Libraries, for example, need to be where programs look for them to be. Programs, too, or they won’t execute when you tell them to. And believe it or not, no matter how confusing you might think the Linux directory structure might be, it is all laid out according to plan. What plan, you ask? That’s an easy question to answer. To find out, just ask the man who has one by entering the following at your friendly command-line:

man hier

On my system, running Red Hat 9, that reveals that the very top of the directory tree is simply “/”. Everything else comes beneath that. One the next level down, we find:

/bin
/boot
/dev
/dos
/etc
/home
/lib
/mnt
/opt
/proc
/root
/sbin
/tmp
/usr
/var

That’s a lot of directories, but each has its own purpose for being there. Some are further subdivided into multiple-levels beneath themselves, as you can see in the output from the man hier command. But this is an introductory discussion, so we’re only going to be concerned with a few of them today: /home, /etc, /bin and /sbin.

Charity begins at /home

Your own personal home directory lives under /home. The big difference here is that unlike DOS/Windows, Linux is a multiuser operating system. And because it is multiuser, it must be able to keep track of a lot of information for each user that would be system-wide on Windows.

Remember putting aliases into .bashrc? That’s because putting it there (beneath /home/username/) keeps it local in scope to you alone rather than global to all users on the system. By the way, just so you know, you can abbreviate /home/username to simply “~/”. Might save you a little typing and it expands to whatever username you are using at the moment. Many applications also keep up with your preferences in configuration files that live in your home directory. That’s why when Susan logs on to my desktop machine, she gets her browser bookmarks loaded instead of mine.

So that’s overkill, you say? There are never going to be any other users on your system other than yourself? Well, not quite. You may be the only regular user to use your PC, but don’t forget root, the SuperUser. Everything specific to root lives in /root rather than a directory below /home. But it is separate from everyone else for the same good reasons that there are individual home directories. Even better reasons, actually. There are things you do as root that you should never do as an ordinary user. I’m not saying you’re not special, I’m just saying you’re not supposed to do ordinary things with SuperUser privileges.

So forth and /etc

System-wide configuration files for programs are typically placed in /etc or in the application’s own subdirectory beneath /etc/. X is one such application. The XF86Config file, for example, lives in /etc/X11/. The services file, which includes the names and port numbers of well-known TCP and UDP services like ftp, ssh, httpd, and so on lives in /etc.

Remember our old friend, .bashrc? Good. There is a bashrc (no period to make it a hidden file this time) in /etc, too. Why? Think globally, act locally, that’s why. The /etc/bashrc file contains system-wide functions and aliases. You actually use both of them, the one in /etc/ and the one in your home directory, not one or the other.

/bin there, done that

Both /bin and /sbin are used to keep programs which are needed to boot the system or repair it. Examples are programs like init, lilo, fsck, and service. Those all live in /sbin, and are normally not executed by normal users. The programs in /bin (like dmesg, chmod, grep, and touch) are in the same general category, but are regularly used by normal users. Users just like you.

The fact that this category of programs has been split into two directories based on whether it is run by root or a normal user should not be lost on you. It’s a recurring theme here in the land of real operating systems.

Choose your own PATH, grasshoppa

We’ve mentioned pathing a couple of times, and I want to be sure that you don’t go any further down the CLI highway without a solid understanding what that means. It’s simple, of course. Pathing is what determines where the system looks for things.

You don’t know what path has been set for you? Don’t worry. We can use a couple of tools we’ve already learned to find out. Plus a new one. The env can be used without any arguments to print all the values of all variables in your current environment. One of those variables is PATH. So from a command line enter:

env | grep PATH

This should print the values of several variables containing the word PATH. On my system, that includes MANPATH, which indicates where all the man pages are kept, LD_LIBRARY_PATH, which points to directories containing software libraries, and PATH itself. When you enter the name of a program, PATH determines where the shell will look to try to find it. If it’s not in any of the directories listed in your PATH, it will simply shrug and say command not found. This can be especially frustrating when you know for a fact that it’s somewhere on your system.

Lost and find (and locate)

So what do you do when you know it’s there somewhere but the shell says no can find? Easy. You find it yourself. Suppose, for example, that you download and install a neat new program called spiffy-sam. Afterwards, when you try to run it, the shell says no dice. So you type at the CLI:

find / -name spiffy-sam

The find command searches every nook and cranny on your system – starting from the point in the directory tree you specify and working its way down from there – looking for a file which matches the name “spiffy-sam”>. You can’t peek in directories that you don’t have permission to read, but find tells you each that that it has skipped for that reason. The search above starts at the very top of the tree, meaning that it is going to look everywhere. If we specify “/usr” instead of simply “/”, find won’t bother looking anywhere but in the /usr directories.

While the find command is very thorough, and that’s a good thing, it can also take nearly forever to finish its search. If you are the impatient type, you might like to use locate instead.

The locate command depends upon the existence of a database containing the name and location of all the files on a system. Normally, Linux distributions schedule a job to run in the middle of the night which rebuilds this database. It’s important that you know that if a file has been created or moved since the last time that updatedb has been run, you won’t be able to locate it. That caveat aside, here’s how you use it at the friendly CLI:

locate spiffy-sam

Both find and locate might return multiple hits for the target file, meaning that there are more than one file with the name you specified on the system. Should that concern you? Sometimes, yes.

Which spiffy-sam

If you have two versions of spiffy-sam, an older one and a new one, it could be critical that you are executing the correct version when you enter spiffy-sam from the command line. The which can tell you which one gets executed. Here’s how you do that:

which spiffy-sam

And guess what magic tool which uses to answer the question? That’s right, my budding Linux-ubergeek, it follows the PATH. When you tell the shell to execute a program, it runs the first one it finds in the PATH.

Let’s say that your PATH includes both /usr/bin and /usr/local/bin, with /usr/bin appearing first in the path. If you have a new version of spiffy-sam in /usr/local/bin, and an older version in /usr/bin, you will never execute the new version of the program. Unless you specify the full path on the command line, that is.

OK, that’s it for this time in the wonderful world of CLI file adventures. That’s not all on the subject, of course. Next time we’ll get into the mysteries of “everything is a file in Unix.”