Introduction to the [linux] terminal

You’ve probably seen it. Specially if you are entering the Linux world, the terminal seems to be everywhere. At first, it may seem intimidating, and to non-techy people it may seem as a “hacking tool”.

In reality, the terminal is just another way of interacting with your computer, one that, while having a steeper learning curve that graphical interfaces, also has its very own set of benefits.

In this article, we are going to discuss what is a terminal, and how we execute programs using it.

But what is a terminal?

In computing, we call shell to a program that allows us to interact with the services that a Operating System provides. The functions of a shell include launching programs, managing already executing programs, give orders to the OS itself, among others.

Then we have a category of shells, the ones which use a command-line interface (CLI) as a way of communication with the user. These are the ones which we colloquially call terminals or consoles.

There are a variety of terminals that allow us to achieve our purposes, for example, in the Unix world (which includes Linux) we have bash, zsh, fish, etc., while Windows has the Command Prompt and PowerShell. In this article, we will use BASH as our reference, since its the default on most Linux systems. It is worth noting that most of the principles discussed here should apply to every Unix terminal.

Executing a program

The main thing we can achieve with a terminal is executing a certain program, often specifying some things on what we want it to do. Executing a program on the terminal will give us some output/response, usually on the terminal itself.

A call to execute a program might look like this

This is a complete example, of a rather complex call, which uses all possible components of a call:

• Program name. It is the name of the program in our system which we want to execute. It is mandatory, and, in a call, it always goes first. In this example, we will execute the DNF program, which should be already in our system (otherwise, we will get an error message).
• Options. We use these to specify how we want our program to behave. An option may specify some data (like the “mycomment” in our example), or go by its own. In Unix/Linux, there are two types of options:
  • Fully named: Preceded by a double dash (–), it is an extended (more legible) option. If we specify some data, we use the syntax --option=value .
  • Shorthand: Preceded by a single dash (-), it is a single letter used to specify an option. Usually a program offers both kind of options (for instance, in our previous example, we might have used either –quiet or -q to specify the same thing), so we can use the full-named or the shorthand version, depending on what we want (better readability or faster typing). If we specify some data, we write it after the option shortand, separated with a space (for example, -n 10).
• Command. It is the task we want the program to perform. I personally like to call it “verb”, to avoid any possible confusion by the use of the word command. In this case, we are telling our program dnf (a package manager) to do the install operation.
• Argument(s). These are the data that we pass directly to a program (not as an option, but rather as direct input). A program may receive one or more, and they are separated by spaces. In our example, we are telling dnf to do the install operation, with the argument “neofetch”. In other words, we are telling it to install a package named “neofetch”.

In reality, most program calls doesn’t use all the call components. For instance, the command/verb is only used in those programs complex enough to perform more that one kind of operation, and sometimes we may not want to specify options at all. Some programs don’t require any arguments, and in some cases, only the program name may be necessary.

Which commands, options or parameters to use?

So yeah, we understand the basic structure of a program call, but how do we know what elements a program may recognize, and what they will do? Do we have to memorize them? Not necessarily, since we have two very useful tools to help us with that.

The first is the system manual, on which we may consult information about a particular program by using man [program which we want to know about]. For example, we can type man man into a terminal to know more about the manual itself

The other way we might learn more about a particular program is with its integrated help, which we may get to by executing the program with the --help or -h options (usually either one should work, however, some programs may only recognize one of them). Executing this will output the program’s integrated help. The response from a program’s integrated help is shorter (and more focused to direct usage) than the manual entry for it.

Next time, I’ll share some terminal Tips & Tricks. See you later!

Featured image by Sai Kiran Anagani on Unsplash