The Terminal & Shell

When you manage a Linux server, you spend most of your time typing commands instead of clicking buttons. That typed-command world is called the command line, and it is reached through two cooperating pieces of software: the terminal and the shell. They sound similar and people often use the words interchangeably, but they are different things. Understanding the difference is the first real step toward becoming comfortable on a server, so let’s pull them apart carefully.

Terminal vs shell vs prompt

These three words describe three separate parts of the same experience. Here is what each one actually is.

Terminal (also called a terminal emulator): the window or app that shows you text and lets you type. On your laptop this is an app like GNOME Terminal, the macOS Terminal, or Windows Terminal. The terminal itself does not understand any commands. It is just a screen and a keyboard for text. Think of it as the telephone handset.
Shell: the program that reads what you type, figures out what you mean, runs the right program, and sends the result back. The shell is the part that actually understands commands like ls or apt. Think of it as the person on the other end of the phone who does the work.
Prompt: the short bit of text the shell prints to tell you it is ready for your next command. It usually shows your username, the machine name, and your current folder.

A typical Ubuntu prompt looks like this:

ubuntu@web-server-01:~$

Reading it left to right: ubuntu is your username, web-server-01 is the server’s hostname, ~ means you are in your home directory (/home/ubuntu), and the $ means you are a normal (non-root) user. If you become the superuser, the $ changes to a # — a small but important visual warning that you now have full power over the machine.

When you see a # at the end of your prompt, you are running as root, the all-powerful admin account. A single mistyped command here can delete critical system files with no “are you sure?” safety net. Prefer staying as a normal user and adding sudo only when a command needs admin rights.

When you use each

On a remote server you almost never see a terminal app on the server itself — there is no screen plugged in. Instead, you open a terminal on your own computer and use it to connect over the network with SSH (Secure Shell, a tool for logging into a remote machine safely). Once connected, the shell that responds to you is running on the remote server. So the terminal is local, the shell is remote, and the prompt tells you which machine you have reached.

Bash: the default shell

A shell is just a program, and there are several to choose from. The most common one — and the default login shell on Ubuntu Server 22.04 and 24.04 LTS (Long-Term Support, the stable versions you run in production) — is Bash (short for “Bourne Again SHell”).

You can confirm which shell you are using:

echo "$SHELL"

Output:

/bin/bash

Other shells exist, and you may meet them on other systems. Here is when each matters.

Shell	Where you’ll see it	When to use it
Bash	Ubuntu, most Linux servers	The safe default for scripts and daily admin; the most documented
sh (dash)	`/bin/sh` on Ubuntu	System boot scripts; very fast and minimal, but fewer features
Zsh	Default on macOS	Interactive comfort, nicer autocompletion; common on laptops
Fish	Opt-in install	Friendly, modern interactive use; not compatible with Bash scripts

For DevOps work on Ubuntu, stick with Bash. It is everywhere, every tutorial assumes it, and your automation scripts will run the same way on every server.

Anatomy of a command

Almost every command you type follows the same three-part shape:

command  [options]  [arguments]

Command — the program you want to run (for example ls, the program that lists files).
Options (also called flags or switches) — small settings that change how the command behaves. Short options start with one dash (-l); long options start with two dashes (--all).
Arguments — the things the command acts on, such as a filename or a directory path.

Here is a real example. The ls command lists the contents of a folder. We add the -l option (long, detailed listing), the -h option (human-readable sizes like 4.0K instead of 4096), and one argument, the path /var/log:

ls -l -h /var/log

Output:

total 6.1M
-rw-r----- 1 syslog   adm  1.2M Jun 15 09:14 auth.log
-rw-r--r-- 1 root     root  18K Jun 15 08:00 dpkg.log
drwxr-xr-x 2 root     root 4.0K Jun 15 06:25 nginx
-rw-r----- 1 syslog   adm  3.4M Jun 15 09:14 syslog

Short options can usually be bundled together, so ls -l -h can be written ls -lh. The two commands are identical:

ls -lh /var/log

Most commands also accept --help to print a quick summary of their options, which is the fastest way to remind yourself of the syntax:

ls --help

Why the command line feels faster

If you are coming from a point-and-click world, the terminal can feel intimidating at first. That feeling fades quickly, and here is why professionals prefer it:

It is exact and repeatable. A command does precisely what it says. You can copy it, paste it into a script, and run it on 100 servers the same way.
It is fast. Typing sudo systemctl restart nginx is quicker than navigating any menu, and it works the same on a server with no graphical interface.
It can be automated. Anything you type by hand can be saved into a script and run automatically — the foundation of all DevOps work.
It works over SSH. Servers in a data centre have no monitor. The command line is often the only way in.

You do not need to memorise hundreds of commands. You will learn a small core set — moving around, reading files, editing config, restarting services — and look up the rest as you go.

Best Practices

Always read the prompt before you act: confirm which server you are on and whether you are root (#) or a normal user ($).
Stay logged in as a normal user and reach for sudo only for the specific command that needs admin rights.
Use Tab completion (press Tab to auto-finish file and command names) to type less and avoid typos.
Stick to Bash for scripts so they run identically across all your Ubuntu servers.
Run an unfamiliar command with --help or read its manual first, especially anything that deletes or overwrites files.
Quote variables and paths that may contain spaces (for example "$HOME/my folder") to avoid surprising errors.