Getting to know the terminal
A more in-depth look at the command line interface
This is an ongoing series. Please check out the collection for the rest of the articles.
Last time, I introduced you to the terminal and argued that despite any initial feelings of apprehension, you’ll eventually learn to love it. There are a lot of reasons to become familiar with command line interfaces. One compelling one is that it can help you become a very efficient programmer. Knowing which commands to run and how to run them takes practice and dedication, especially compared to how quickly graphical interfaces can be learned, but the return on investment is well worth the trouble. Of course, the real appeal of the terminal is that you can use it to play the ASCII version of Star Wars, seen above.
With that in mind, let’s get more comfortable with text-based interaction. We left off last time having briefly discussed ls and cd; let’s return to these commands and examine them in more detail. We’ll start in the UCS directory, mentioned last time, where I keep all the files relevant to these blog posts:
You might have noticed that the prompt is different than the one last time — this is my custom prompt. There are good tutorials on how to do it (it’s not hard!) and I’ll explain how later, but don’t worry if your prompt doesn’t match mine exactly. It’s a purely cosmetic difference.
Anyway, ls reveals that there are many directories, one for each post, as well as a number of files. What if we want to see the contents of today’s post, in the 30-getting-to-know-the-terminal directory? One way is to first cd into 30-getting-to-know-the-terminal and then use ls. (Note how I used cd as a verb; this is part of becoming familiar with the shell). But cding into a directory just to see its contents would be tedious. Instead, we can tell ls to list any directory we want, even if it’s not the current working directory. Simply enter the directory name after ls, separated by a space:
Here are the results:
As the prompt indicates, we’re still in UCS but the results are clearly from a different directory, in this case 30-getting-to-know-the-terminal. This option makes ls a more useful tool than it would otherwise be. However, it also raises a question: we saw from last time that ls has another option, -l, so how do we use both? What if we want to view the detailed contents of another directory? The answer is fairly intuitive: add both of the desired options, or arguments, to ls:
This in turn raises another question: in what order do we add the arguments? It turns out that the answer is program-dependent — that is, different programs have different rules about it. This is because the terminal sends programs like ls an array of arguments given to it. The program decides how to interpret them. For ls, it doesn’t matter. Actually, you can pass any number of directories ls and it will list all their contents in a row, like this:
Remember that 20-hello-world and 21-the-issue-of-types are directories inside UCS, our working directory. As you can see, 21-the-issue-of-types has nothing in it — that article didn’t contain any images or code.
For the most part, Linux does not care what you name your files or directories — it does not discriminate between textual names like fonts and numeric names like 1 and 2. File and directory names can have any combination of letters, numbers, and symbols except the forward slash (/), although including spaces in a name can cause certain difficulties. The names can even include many Unicode characters, although some of them can cause problems.
There are still many questions concerning ls that we haven’t yet examined. For instance, how do you reference a directory somewhere else on the computer? Does “ls some-directory” search the whole system for a directory named some-directory? No:
I probably don’t have a directory named some-directory anywhere, but even if I did it wouldn’t show up here. It’s easy to forget where you are, so use the pwd command, which stands for “print working directory”, to see where your working directory is located:
All locations start with a slash (/). This slash refers to the topmost directory, inside of which everything else is stored. This directory is called the root directory because if you view the hierarchy of directories and files as a tree, it is the root, or trunk, from which everything else branches out.
/home refers to the home directory within the root directory, /. Similarly, /home/jack refers to the jack directory within the home directory. And so on. /home/jack is called the path of jack, because it is the trail of directories leading to jack. Paths allow each directory to be uniquely identified and located.
But using the full path of a directory every time you wanted to refer to it would be obscenely cumbersome. Luckily, we don’t have to use the full path, as you can see from the previous examples of ls and cd. If a file or directory is directly within your working directory, you can refer to it by just its name. Extending this, if a file or directory is somewhere nested within your working directory, then you can refer to it with its relative path that specifies where it is relative to your current location. An example:
If everything but the tilde (~) above is obvious to you then please keep reading. If you’re not quite sure what’s going on in the example above, try working through it line by line until you understand. Remember that each line with a command starts with the green prompt — the rest is the computer’s response. Think of it like a conversation with your computer.
It’s worth noting some shortcuts that make navigating more efficient. The working directory can be referenced with a single dot (.). This is not very useful for ls and cd, but there are many instances in which you need to pass your current directory to an application and a single dot is a lot more convenient than /lots/of/directories/like/this. Using two dots in a row (..) refers to the parent directory, which is the directory that contains your working directory. So the parent directory of 30-getting-to-know-the-terminal is UCS and the parent of UCS is Documents.
On Linux, your personal files are stored in your home directory. This is almost always located at /home/username, where username is whatever your username is (in your case, this is the name you picked for your account when you installed Fedora). So my home directory is /home/jack. You might have spotted a shortcut in the example above; a shorter way to refer to your home directory is to start the path with a tilde (~):
~/UCS means “the file or directory named UCS directly within the home directory”. While this may seem like an overly technical point to mention in an introductory article, it’s shortcuts like “~ refers to /home/jack” that make using the terminal so efficient. I’ll mention plenty more shortcuts in the future.
Now that we’ve established how to navigate around the file system, let’s setup a directory to experiment in. Move to your home directory and create a directory named code:
You may have just inferred that mkdir stands for “make directory”. While abbreviations like ls, pwd, and mkdir can take some time to memorize, they save time in the long run by taking less time to type.
Let us appreciate your newly created directory by cding into it and listing its contents:
Of course, there’s nothing there! So let us create a file. To keep it simple, it will be a plain text file — a file that contains a sequence of letters, numbers, and symbols. In other words, the file is treated as one long string. Here is one of many ways to create a new text file:
Despite its brevity, this command needs quite a bit of explanation. We’ll start at the beginning: what does echo do? As the name suggests, echo prints out whatever string you give it, echoing it back. If you just call echo, followed by a string, it prints the string back to the terminal:
We don’t want to print the string back to the terminal, however; we want to print it to a file called, say, notes.txt. We can do that with the redirection operator, >. This operator, represented by a greater-than symbol, takes the output of the program to its left and saves it to the file on its right. You can save to files in other directories by specifying the file’s absolute or relative path:
And you don’t have to use echo — any text will do:
The above command prints the output of ls to a file named directory-contents.txt. Stepping back a second, after we call
we can check to see if the new file exists with ls:
How do we check the contents of notes.txt? With cat, which is short for “concatenate”, not our furry companions (but you can pretend it refers to cats if you want — I won’t judge you). As expected, notes.txt contains “I am a string!”:
Perhaps unexpectedly, standard shell programs in Linux do not care about file extensions, so the .txt in notes.txt matters only to us humans. Because so many files in programming environments contain only text, many plain text files are not given file extensions. We can adopt this tradition by renaming our file to notes:
You might be trying to figure out what mv stands for. You can try guessing, but I don’t think it’s obvious in this context. Answer: mv stands for “move” because that’s what renaming a file is — by renaming the file, you’re moving where it’s located in the file system. An important side note is that you’re not actually moving the contents of the file — that would require copying all of its data, a costly operation for large files. Rather, you’re changing the name that refers to the file, leaving the file’s contents untouched.
So mv lets us rename notes.txt to notes, as ls confirms:
As with ls, cd, cat, and most other shell programs, anytime the name of a file can be given, a path to a distant file can also be given. For instance,
would move the notes file to ~/more_code/more_notes, assuming a directory named more_code exists in your home directory (otherwise mv will print an error letting you know it didn’t understand your request). Note that when you’re working in the ~/code directory, ../more_code refers to ~/more_code — this kind of mental calculation will happen instantly and subconsciously after you’ve gotten a little practice with CLIs.
This post contains a lot of information, so I want to wrap it up with just two more useful programs, cp and rm. cp stands for “copy” and copies the contents of the first given file to the second. Thus,
copies the contents of file1 to file2, overwriting whatever was there. That last point is important — neither mv nor cp warns you if you’re about to overwrite existing information. Neither does rm, which stands for “remove”. While rm normally refuses to remove directories, the following command recursively removes, without warning, all of the files and directories within your home directory:
Please don’t enter that into your terminal if you have anything of value stored anywhere within your home directory. Luckily, typing
does not actually delete the home directories of every user in the system. Unless, that is, you have superuser privileges. Then rm does delete everything, not only unapologetically, but completely unaware of the external meaning and consequences of its actions. There could be several hundred users, each with a home directory full of important documents, and the command above, if run by a superuser, would delete everything in a matter of seconds. (Takeaway: back up your data!)
We’ll talk more about what it means to be a superuser and discuss other access permissions topics next time.
