Welcome Guest | Sign In
LinuxInsider.com

The Terminal Is Where Linux Begins - and Where You Should, Too

By Jonathan Terrasi
Mar 8, 2017 1:43 PM PT
linux-terminal-command-line

Once you have a sense of the vast potential of Linux, you may be eager to experience it for yourself. Considering the complexity of modern operating systems, though, it can be hard to know where to start.

As with many things, computers can be better understood through a breakdown of their evolution and operation. The terminal is not only where computers began, but also where their real power still resides. I'll provide here a brief introduction to the terminal, how it works, and how you can explore further on your own.

Terminal, Command Line, Shell

Although "terminal," "command line," and "shell" are often used interchangeably, it helps to learn the general distinctions between these terms. The word "terminal" comes from the old days of Unix -- the architecture on which Linux is based -- when university campuses and research facilities had a room-sized computer, and users interacted with it by accessing keyboard-and-screen terminals scattered around the campus and connected to the central hub with long cables.

Today, most of us don't deal with true terminals like those. Instead, we access emulators -- interfaces on Unix-like systems that mimic the terminal's control mechanism. The kind of terminal emulator you're most likely to see is called a "pseudo-terminal."

Also called a "terminal window," a pseudo-terminal is an operating system application on your normal graphical desktop session. It opens a window allowing interaction with the shell. An example of this is the Gnome Terminal or KDE Konsole. For the purpose of this guide, I'll use "terminal" to refer exclusively to terminal emulators.

The "command line" is simply the type of control interface that one utilizes on the terminal, named for the fact that you write lines of text which are interpreted as commands.

The "shell" is the program the command line uses to understand and execute your commands. The common default shell on Linux is Bash, but there are others, such as Zsh and the traditional Unix C shell.

File Organization

The last thing you need to know before diving in is how files are organized. In Unix-like systems, directories are ordered in an upside down tree, with the root filesystem (notated as "/" and different from the "/root" directory) as the starting point.

The root filesystem contains a number of directories within it, which have their own respective directories and files, and so on, eventually extending to encompass every file your computer can access. The directories directly within the root filesystem, in directory notation, are given right after the "/".

For example, the "bin" directory contained right inside the root would be addressed as "/bin". All directories at subsequent levels down are separated with a "/", so the "bin" directory within the "usr" directory in the root filesystem would be denoted as "/usr/bin". Furthermore, a file called "bash" (the shell), which is in "bin" in "usr" would be listed as "/usr/bin/bash".

So how do you find these directories and files and do stuff with them? By using commands to navigate.

To figure out where you are, you can run "pwd" ("print working directory") and you will get the full path to the directory you're currently in. (Note that in all code snippet examples, the frist "$" represents the command prompt, the string of text on every line before the command you enter.)

$ pwd

To see where you can go, run "ls" to list directory contents.

$ ls

When run by itself, it returns the contents of the current directory, but if you put a space after it and then a path to a directory, it will print the contents of the directory at the end of the path.

$ ls /directory/another_directory

Using "ls" can tell you more than that, though. If you insert "-l" between the command and the path with a single space on either side, you will get the "long" listing specifying the file owner, size and more.

$ ls -l

Commands, Options, Arguments

This is a good time to explain the distinction between commands, options and arguments. The command, which is the program being run, goes first.

After that you can alter the functionality of the command by adding options, which are either one dash and one letter ("-a") or two dashes and a word ("--all").

$ ls -a
$ ls --all

The argument -- the thing the command operates on -- takes the form of a path. Many commands do not need arguments to provide basic information, but some lend far greater functionality with them, or outright require them.

Things to Do

The next step is moving between directories, which you do by running "cd" ("change directory").

$ cd

If you supply a path as an argument, it will move you to that directory. If you don't, it will return you to the user's home directory (e.g., for user "pablo", "/home/pablo").

$ cd /home/pablo

There are two kinds of paths -- absolute and relative. Absolute paths, or full paths, are ones that start from root. However, you also can give a path from the directory you're in, in which case it is relative.

Now that you know how to find files, you'll want to be able to do something with them. One option is to copy them with "cp". To use it, you must supply two arguments, separated by a space: the file to be copied, and where you want it to go.

$ cp original copy

If the second argument is a directory, it will place an exact copy there, but if it is a filename, it will place a copy with the given filename in the directory before the last slash.

Be aware that if a file already exists at the same place and with the same name as the second argument, the former will be overwritten.

You also can move files with the "mv" command. As with "cp", "mv" takes the original file as the first argument and the new location as the second. Also like "cp", if the second argument is a file name, it will rename the file to that.

$ mv original_location new_location

The overwriting, or "clobbering," rule of "cp" applies to "mv", too.

Off You Go

These are just the basics, but knowing them is sufficient for you to explore the system. One key to success in learning computers is to realize that it doesn't require learning every minute detail, but rather learning how to learn.

In that spirit, I want to leave you with a few resources for answering your own questions -- though you can certainly ask others, including me!

If you want to examine what's in a file without accidentally messing it up, run "less" with the file as an argument.

$ less filename

This opens it with a viewer, which prevents you from editing, giving you free rein to scroll through at your leisure.

If you're not sure what kind of file something is, run "file" on it (again, with the file as the argument).

To get an idea of what command might be useful in a certain situation, you can run "apropos" with a keyword and you'll receive a list of relevant programs.

$ apropos keyword

If you want to get a sense of what a command does, along with a reference sheet for the options and arguments a command can take, you can run "man" (for "manual") followed by the command name.

$ man command_name

In future installments, I plan to demonstrate some of the terminal's more advanced capabilities, but if you're looking to supplement this introduction, I recommend checking out "The Linux Command Line," a free PDF by William Shotts.

Another good resources is the beginner Linux video series "Linux Terminal -- Getting Started!" by hak5.

This should be more than enough to keep even the most ambitious of you busy until my next installment appears. Until then, happy terminal testing!

Editor's Note - March 13, 2017: The original published version of this article did not include code snippet examples. Author Jonathan Terrasi added them in response to reader durandaltheta's helpful suggestion.


Jonathan Terrasi has been an ECT News Network columnist since 2017. His main interests are computer security (particularly with the Linux desktop), encryption, and analysis of politics and current affairs. He is a full-time freelance writer and musician. His background includes providing technical commentaries and analyses in articles published by the Chicago Committee to Defend the Bill of Rights.


Facebook Twitter LinkedIn Google+ RSS
How urgent is the need to provide broadband services for rural U.S. communities?
It's critical to the entire economy, and everyone should share the cost.
If rural residents really want high-speed Internet, they should foot the bill.
Internet providers will benefit -- they should build out their own networks.
The government should ensure that everyone is connected, but broadband isn't necessary.
People who choose to live off the grid do so for a reason -- leave them alone.
Providers should improve broadband services in heavily populated areas first.