Author’s note: This article is excerpted in part from chapter 6 of my book, The Linux Philosophy for SysAdmins, with some changes.

The Force is with Linux and the Force is the Command Line Interface – the CLI. The vast power of the Linux CLI lies in its complete lack of restrictions. In this article we will begin to explore the command line in ways that will illuminate the power that it literally places at your fingertips.

There are many options for accessing the command line such as virtual consoles, many different terminal emulators, and other related software that can enhance your flexibility and productivity. All of those possibilities will be covered in this article as well as some specific examples of how the command line can perform seemingly impossible tasks – or just satisfy the pointy haired boss.

Defining the command line

The command line is a tool that provides a text mode interface between the user and the operating system. The command line allows the user to type commands into the computer for processing and to see the results.

The Linux command line interface is implemented with shells such as Bash (Bourne again shell), csh (C shell), and ksh (Korn shell) to name just three of the many that are available. The function of any shell is to pass commands typed by the user to the operating system which executes the commands and returns the results to the shell. Since Bash is the default shell for most Linux distributions, that’s what I’ll use in this article.

Access to the command line is through a terminal interface of some type. There are three primary types of terminal interface that are common in modern Linux computers but the terminology can be confusing. So let’s define those terms as well as some other terms that relate to the command line.

CLI terminology

There are several terms relating to the command line that are often used interchangeably. This indiscriminate usage of the terms caused me a good bit of confusion when I first started working with Unix and Linux. I think it is important for SysAdmins to understand the differences between the terms console, virtual console, terminal, terminal emulator, a terminal session, and shell.

Of course you can use whatever terminology works for you so long as you get your point across. Within this article, I will try to be as precise as possible because the reality is that there are significant differences in the meanings of these terms and it sometimes matters.

Command prompt

The command prompt is a string of characters like this one that sits there with a flashing cursor, waiting – prompting – you to enter a command. This first example is typical of the Bash prompt for Fedora 39 and earlier.

[tuser1@testvm1 ~]$ █

This version of the Bash command prompt is from Fedora 40.

tuser1@testvm1:~$ █

The typical command prompt in a modern Linux installation consists of the user name, the host name, and the present working directory (PWD), also known as the “current” directory, all enclosed in square braces. The tilde (~) character indicates the home directory.

The command prompt is defined in the $PS1 through $PS4 environment variables and can be changed by the user as desired. Look at the current value of the $PS1 environment variable.

tuser1@testvm1:~$ echo $PS1
${PROMPT_START@P}\[\e[${PROMPT_COLOR}m\]${PROMPT_USERHOST@P}\[\e[0m\]${PROMPT_SEPARATOR@P}\[\e[${PROMPT_DIR_COLOR:-${PROMPT_COLOR}}m\]${PROMPT_DIRECTORY@P}\[\e[0m\]${PROMPT_END@P}\$\[\e[0m\]

That’s a very long prompt but it results in the Fedora 40 command prompt. You can find information about the command prompts PS1 through PS4 in the Bash man page. Search on PS1.

Command line

The command line is the line on the terminal that contains the command prompts and any command you enter. The terms command prompt and command line are sometimes used interchangeably.

Command Line Interface

The Command Line Interface is a text mode user interface to the Linux operating system that allows the user to type commands and see the results as textual output.

Terminal

A terminal is an old bit of hardware that provides a means of interacting with a mainframe or Unix computer host. The terminal is not the computer; the terminals merely connect to the mainframes and Unix systems. Terminals – the hardware type – are usually connected to their host computer through a long serial cable. Terminals such as the DEC VT100 shown in Figure 1 are usually called “dumb terminals” because they have just enough logic in them to display data from the host and to transfer keystrokes back to the host. All of the processing and computing is performed on the host to which the terminal is connected.

Terminals that are even older, such as mechanical teletype machines (TTY) predate the common use of CRT displays. They used rolls of newsprint-quality paper to provide a record of both the input and results of commands. The first college course I took on computer programming used these TTY devices which were connected by telephone line at 300 bits per second to a GE (yes, General Electric) time-sharing computer a couple hundred miles away. Our university could not afford a computer of their own at that time.

Much of the terminology pertaining to the command line is rooted by historical usage in these dumb terminals of both types. For example the term TTY is still in common use but I have net seen an actual TTY device in a many years. Look in the /dev directory of your Linux or Unix computer and you will find a large number of TTY device files.

Terminals were designed with the singular purpose of allowing users to interact with the computer to which they were attached by typing commands and viewing the results on the roll of paper or the screen. The term, “terminal,” tends to imply a hardware device that is separate from the computer while being used to communicate and interact with it.

Console

A console is a special terminal because it is the primary terminal connected to a host. It is the terminal at which the system operator would sit to enter commands and perform tasks that were not allowed at other terminals connected the host. The console is also the only terminal on which the host would display system level error messages when problems occurred.

There can be many terminals connected to mainframe and Unix hosts, but only one is or can act as a console. On most mainframes and Unix hosts, the console was connected through a dedicated connection that was designated specifically for the console.

On a PC the physical console is usually the keyboard, monitor, and sometimes the mouse (KVM) that are directly attached to the computer. These are the physical devices used to interact with BIOS during the BIOS boot sequence, and can be used during the early stages of the Linux boot process to interact with GRUB and choose a different kernel to boot or modify the boot command to boot into a different run level.

Virtual console

Modern personal computers and servers that run Linux do not usually have dumb terminals that can be used as a console. Linux typically provides the capability for multiple virtual consoles to allow for multiple logins from a single keyboard and monitor. Red Hat Linux, CentOS and Fedora Linux usually provide for six or seven virtual consoles for text mode logins. If a graphical interface is used, the first Virtual console, vc1, becomes the first graphical (GUI) session after the X Window System (X) starts. and vc7 becomes the second GUI session.

Each virtual console is assigned to a Function Key corresponding to the console number. So vc1 would be assigned to function key F1, and so on. It is easy to switch to and from these sessions. On your computer you can hold down the Ctrl-Alt keys and press F2 to switch to vc2. Then hold down the Ctrl-Alt keys and press F1 to switch to vc1 and what is usually the graphical desktop interface. If there is no GUI running, vc1 will be simply another text console. Figure 2 shows the login prompt for virtual console 2.

Virtual consoles provide a means to access multiple consoles using a single physical system console, the keyboard, video display and mouse (KVM). This gives administrators more flexibility to perform system maintenance and problem solving. There are some other means for additional flexibility, but Virtual Consoles is always available if you have physical access to the system or directly attached KVM device or some logical KVM extension such as Integrated Lights Out, or ILO. Other means such as the screen command might not be available in some environments and a GUI will probably not be available on most servers.

Terminal emulator

A terminal emulator is a software program that emulates a hardware terminal such as the VT100. Most of the current terminal emulators can emulate several different types of hardware terminals. Most terminal emulators are graphical programs that run on any Linux graphical desktop environment like KDE, Cinnamon, LXDE, GNOME, and others. The Linux Console is the terminal emulator for the Linux virtual consoles.

The first terminal emulator was Xterm which was originally developed in 1984 by Thomas Dickey. Xterm is still maintained and is packaged as part of many modern Linux distributions.

My favorite terminal emulator is Konsole because it offers the ability to have many terminal emulator sessions in a single window. Konsole does this using multiple tabs that I can switch between as well as the ability to display multiple terminal sessions in the same tab.

Other terminal emulators include Tilix, rxvt, gnome-terminal, Terminator, and many more. Each of these terminal emulators has a set of interesting features that appeal to specific groups of users. Some have the capability to open multiple tabs or terminals in a single window. Others provide just the minimum set of features required to perform their function and are typically used when small size and efficiency are called for.

Pseudo Terminal

A pseudo terminal is a Linux device file to which a terminal emulator is attached in order to interface with the operating system. The device files for pseudo terminals are located in the /dev/pts directory and are created only when a new terminal emulator session is launched. That can be a new terminal emulator window or a new tab or panel in an existing window of one of the terminal emulators, such as Konsole, that supports multiple sessions in a single window.

The device files in /dev/pts are simply a number for each emulator session that is opened. The first emulator would be /dev/pts/1, for example.

Session

Session is another of those terms that can apply to different things and yet it retains essentially the same meaning. The most basic application is a to terminal session. That is a single terminal emulator connected to a single user login and shell. So in its most basic sense a session is a single window or virtual console logged into a local or remote host with a command line shell running in it.

Shell

A shell is the command interpreter for for the operating system. Each of the many shells available for Linux interprets the commands typed by the user or SysAdmin into a form usable by the operating system. When the results are returned to the shell program, it displays them on the terminal.

The default shell for most Linux distributions is the bash shell. bash stands for Bourne Again Shell because the bash shell is based upon the older Bourne shell which was written by Steven Bourne in 1977. Many other shells are available. The four I list here are the ones I encounter most frequently but many others exist.

• csh – the C shell for programmers who like the syntax of the C language.
• ksh – the Korn shell, written by David Korn and popular with Unix users.
• tcsh – a version of csh with more ease of use features.
• zsh – which combines many features of other popular shells.

All shells have some built-in commands that supplement or replace the commands provided by the core utilities. Open the man page for bash and find the “BUILT-INS” section to see the list of commands provided by the shell itself.

I have used the C shell, the Korn shell and the Z shell. I still like the bash shell better than any of the others I have tried. Each shell has its own personality and syntax. Some will work better for you and others not so well. Use the one that works best for you, but that might require that you at least try some of the others. You can install four shells as root if they’re not already.

# sudo dnf -y install csh ksh tcsh zsh

You can temporarily change shells easily. Simply type the name of the shell on the command line like any other command. When you’re finished with that shell, enter exit or logout. You can try each of those terminal emulators using this method.

tuser1@testvm1:~$ ksh
$ ls                                                                                                                                                                        
admin.index  Desktop  diskusage.txt  Documents  Downloads  Music  Pictures  Public  Templates  toprc  Videos
$ exit
tuser1@testvm1:~$

You can permanently change your shell with the chsh command so that it will be persistent every time you login and start a new terminal session.

If you have a script which runs other commands – which is the purpose of a script – the script runs each command, waiting for it to finish before moving on to run the next command.

That behavior can be modified by appending an ampersand (&) to the end of a command, which places the called command in the background and allows the user to continue to interact with the shell, or for the script to continue processing more commands. You would only want to do this with commands that do not require further human interaction or output to STDOUT. You would also not want to run commands in the background when the results of that command are needed by other commands that will be run later, but perhaps before the background task has finished.

Secure Shell (SSH)

SSH is not really a shell. The ssh command starts a secure communication link between itself as the client and another host with the SSHD server running on it. The actual command shell used at the server end is whatever the default shell set for that account on the server side, such as the Bash shell.

screen

You might at first think of “screen” as the device on which your Linux desktop is displayed. That is one meaning.

For geeks like us, screen is also a program, a screen manager, that enhances the power of the command line. The screen utility allows launching multiple shells in a single terminal session and provides means to navigate between the running shells.

I have had remote connections fail many times, particularly in the past with slow modems and bad phone lines. But it can also happen now if my internet connection fails. When that happened the running program was terminated as well and I had to restart it from the beginning. It could get very frustrating.

The screen program can prevent that. A screen session will continue to run on the remote host even if the connectivity is broken because the network connection fails. It also allows disconnecting the screen session from the terminal session and reconnecting later from the same or a different computer. All of the CLI programs running in the screen terminal sessions will continue to run on the remote host. This means that once communications is reestablished one can log back into the remote host, use the screen -r command at the remote command line to reattach the screen session to the terminal.

I can start up a bunch of terminal sessions in screen, use Ctrl-a + d to disconnect from screen and log out. Then I can go to another location, login to a host, SSH to the host running screen, login and use the screen -r command to reconnect to the screen session and all of the terminal sessions and their respective programs will still be running.

The screen command can be useful in some environments where physical access to a hardware console is not available to provide access to the Virtual Consoles but the flexibility of multiple shells is needed. You will probably find it convenient to use the screen program and in some cases it will be necessary to do so in order to work quickly and efficiently.

I use the screen program all the time. It is a powerful tool that provides me with extreme flexibility for working on the command line.

Non-restrictive interface

The Linux CLI is a non-restrictive interface because it places no limits on how you use it. A GUI is by definition a very restrictive interface. You can only perform the tasks you are allowed in a prescribed manner and all of that is chosen by the programmer. You cannot go beyond the limits of the imagination of the programmer who wrote the code or – more likely – the restrictions placed on the programmer by the Pointy Haired Bosses.

CLI power

I hope you can see from these simple examples, just a little of the vast power available to the SysAdmin when using the command line. Linux provides a very large number of methods to access the command line and perform your work as a SysAdmin. You can use the virtual consoles and any of a number of different terminal emulators. You can combine those with the screen program in order to further enhance the flexibility you have at the command line.

The examples in this chapter are informative in themselves, but the real power of the CLI comes from the fact that I also “Automate everything” using that CLI, which is another tenet of the philosophy. It is well known by experienced SysAdmins that if something needs to be done once, it will need to be done again, usually many times. so to make it easy later I placed those simple lines of bash code in text files and made the files executable. Whenever I was asked to provide that same information again, all I had to do was to run the appropriate bash script.