Module 1: The Terminal and the File System

2. What is a shell and why the terminal still wins

Description

By the end of this lesson you will be able to distinguish four words that in practice everybody mixes up — terminal, shell, prompt, and console — and, more importantly, you will be able to decide with judgment when it makes sense to open a terminal and when it makes sense to simply click through a graphical interface. This is not an academic question: in any technical job you are going to run into the person who says "my terminal does not recognize that command" when the real problem is in another layer, or the decision of whether to automate a repetitive task or do it by hand one more time. Knowing which piece failed — or which piece is the right one to use — saves you hours.

Connection to the module: the previous lesson showed you the full map of this guide. This one gives you the exact vocabulary for the pieces you are going to work with over the next four modules, before lesson 3 has you open a real terminal on your own operating system.

Terminal, shell, prompt, and console: four words, four different jobs

Before screens like yours existed, large computers (mainframes) lived in a separate room, and several people used them at the same time from other rooms, sometimes other buildings. To do that, they connected a device with a keyboard and screen — or before that, even a printer — by a cable to the central computer. That device did not compute anything on its own: it only sent what you typed and displayed what the central computer sent back. That device was called a terminal, because it was the final end (terminal, from the Latin "that which ends") of a communication line. When the operator sat directly in front of the central computer, with no cable or line in between, that station was called a console.

Today there are no mainframes in the next room, but the vocabulary survived because the model is still useful:

Terminal: the program that draws the window on your screen — Terminal.app, iTerm2, Windows Terminal, GNOME Terminal, Konsole. It is an emulator: it imitates how that cabled device used to behave, but it runs entirely inside your computer. The terminal does not understand what you type; it only captures your keystrokes and draws whatever gets sent back to it.
Shell: the program that does understand what you type. It runs inside the terminal window, reads every line that reaches it, decides what it means, and asks the operating system to carry it out. bash and zsh are shells.
Prompt: the line waiting for you, the one that says "I am ready for your next order." It normally shows your user, the machine's name, and where you are standing, and it ends in a symbol — $, %, or # — that also carries information, as you will see in a moment.
Console: today it survives with a narrower meaning. It is used for direct access to a machine, without going through a remote connection — for example, when a cloud provider offers you "console access" to a virtual server that is not responding over the network, or when someone says "connect over serial console" to a router. It is the difference between being physically in front of the equipment (or its virtual equivalent) and arriving over a communication line.

Worked example

Let us see what really happens, layer by layer, when you type something as simple as this in an open terminal:

$ echo "hello from the shell"
hello from the shell
$

What to expect, in order:

The terminal captures every key you press and draws it on screen, but it does not know what echo means. It is a notepad that jots things down, not an interpreter.
When you press Enter, the terminal hands the complete line (echo "hello from the shell") to the shell running inside that window.
The shell recognizes echo as an order it knows how to run, and recognizes that the text in quotes is what it should display. It asks the operating system to print that text to standard output.
The result (hello from the shell) travels back to the shell, which hands it to the terminal.
The terminal draws that text in the window and, once the shell is done, shows the prompt ($) again, ready for your next order.

Notice that across those five steps, the terminal only shows up at the beginning and the end — drawing input and output. All the work of understanding what echo meant was done by the shell. That is exactly why "my terminal does not recognize this command" is almost never a terminal problem: the terminal does not recognize anything, it never did.

bash and zsh: the same idea, two implementations

Several shells exist (sh, csh, bash, zsh, fish, among others), but the two you are going to run into all the time are:

bash (Bourne Again SHell): created in 1989 by the GNU project. It is the default shell on the vast majority of server Linux distributions — Ubuntu, Debian, RHEL, Fedora, Amazon Linux — and therefore the one you are going to find when you connect over SSH to almost any server in the cloud.
zsh (Z shell): largely compatible with bash syntax, but with more built-in features — smarter autocompletion, typo correction, better history handling. It has been the default shell on macOS since Catalina (10.15, October 2019).

Why the difference? Apple publicly explained that it could not keep updating bash on macOS: bash versions starting with 4 are distributed under the GPLv3 license, and Apple decided not to adopt that license in its operating system. Bash stayed frozen at version 3.2 (from 2007) inside macOS, while zsh — under a different license — could keep being updated. That is why Apple changed the default.

The practical implication for you: if you open a terminal on your Mac and another one on a Linux server, you are probably running two different shells without noticing, and that can explain why the same command behaves slightly differently on each one (some advanced bash syntax does not work the same in zsh, and vice versa). You do not need to resolve those differences yet — that comes when you write scripts — but it is worth knowing they exist and why.

A quick visual clue for knowing which one you are using, without needing a dedicated command yet (we will verify this formally in the next lesson): the symbol your prompt ends in usually gives it away. By tradition, shells in the Bourne family (sh, bash) end their prompt in $; shells in the C family (csh) and zsh inherited the habit of ending in %. It is not an absolute rule — all of this is configurable — but on a freshly installed setup, without customization, that difference is usually there.

When the graphical interface wins and when there is no substitute for the terminal

Here it is worth being honest: the terminal is not "more professional" than clicking. It is a different interface, with concrete advantages on concrete tasks, and with a real cost of entry — you have to remember syntax instead of recognizing a button. Nobody earns a moral point for preferring it.

The graphical interface clearly wins when:

You are exploring something you do not know. If you have never seen a project's folder structure, a file explorer with icons and previews gives you a complete picture at a glance. Typing command after command to "see what is there" is slower than looking.
The task is visual by nature. Editing an image, adjusting an interface's layout, moving elements around with the mouse until "they look right": there, a GUI's immediate visual feedback has no reasonable substitute in text.
It is a one-time task, with no repetition and no need to leave a record. Renaming a single stray file, moving three folders: doing it by hand is faster than learning the syntax to automate it.

The terminal wins hands down when:

The task repeats. If you are going to do the same thing ten times — or ten thousand — a command (or a script a few lines long) does it identically all ten thousand times. A click repeated ten thousand times will, at some point, fail from human fatigue.
You need to compose small tools with each other. In the terminal you can take one program's output and use it as another program's input (this is called a pipe, and you will see it in the pipes and redirection module). A graphical interface normally does not let you chain programs like that.
The machine has no screen. A cloud server, a container, a Raspberry Pi running headless: you connect to all of them through a remote terminal, because there is no other possible interface.
You need to leave a reproducible record of what you did. A command — or a script saved to a file, versionable with Git — documents exactly what ran and how. A sequence of clicks leaves no such trail; if something went wrong, nobody can reconstruct what happened.

Concrete professional relevance: when you are asked to deploy the same configuration to 200 servers, or check the logs of a cloud server that has no screen, or repeat an analysis on new data every week, the question is no longer "do I prefer clicking or typing?" — it is that clicking simply does not scale to the job. That is where the terminal stops being a preference and becomes the only tool that gets the whole job done.

Common mistakes

1. Confusing terminal with shell (conceptual error). What happens: someone switches terminal emulators (say, from Terminal.app to iTerm2) expecting it to fix a problem with commands it does not recognize, or says "my terminal has no autocompletion" when autocompletion is a shell feature, not a terminal one. Why it happens: the terminal is the only visible part — the window, the colors, the tabs — so it is natural to attribute all behavior to it. How to spot it: if the problem persists after switching terminal emulators (same shell running inside), the problem is not the terminal. How to fix it: identify which shell is running and check its configuration, do not reinstall the window program.

2. Confusing "console" with "terminal" in cloud contexts. What happens: someone hears "open the AWS console" or "the admin console" and expects a text window with a prompt, but finds a web panel full of buttons. Why it happens: the name "console" got reused for web admin panels (AWS Console, Azure Portal) that have nothing to do with a command line; it is a coincidence of naming, not of function. How to spot it: if you are handed a link or an "Open console" button inside a browser, it is a graphical panel, not a terminal. How to fix it: if you genuinely need a terminal over that resource, look for the specific option — usually called "connect via SSH" or "serial console session" — that actually opens a real shell.

3. Assuming zsh on Linux behaves exactly the same as on macOS. What happens: someone installs zsh on a Linux server expecting the same % prompt and the same features it had on their Mac, and finds a "bare" shell, with no advanced autocompletion or configuration. Why it happens: on macOS, Apple not only installed zsh, it also set up a default configuration for it; on Linux, zsh usually installs with no configuration file of its own. How to spot it: a prompt with no colors or extra information, very different from the one you remembered. How to fix it: understand that zsh (the program) and zsh's configuration (the .zshrc file) are separate things — a topic we come back to when we work with shell configuration files.

Exercises

Exercise 1. You open Terminal.app on your Mac. You see a blinking cursor next to the text mike@MacBook-Pro ~ %. You type echo hello and press Enter; on the next line, hello appears. In this scenario, identify which is the terminal, which is the shell (and why you can guess which one it is, without having verified it yet with a command), and which is the prompt.

See solution

Terminal.app is the terminal: the window, the emulator that draws the text. The shell is the program that interpreted echo hello and returned hello — and you can guess it is zsh because the prompt ends in %, the traditional symbol for that family of shells (on an uncustomized setup). The prompt is the full line mike@MacBook-Pro ~ %, the one waiting for your input and showing user, machine, and location.

Why it works: the final symbol of the prompt (% versus $) is a reliable visual clue to the shell family, because each family adopted a different symbol by tradition for its default prompt.

Exercise 2. You work in tech support and get asked: "on 300 company laptops, find every file older than two years in each user's Downloads folder and delete them, keeping a record of what was deleted on each machine." Would you use the graphical interface (file explorer) or the terminal? Justify with at least two reasons from this lesson.

See solution

Terminal. Two concrete reasons from the lesson: (1) it is a task that repeats identically 300 times — exactly the case where a command or script runs the same way all 300 times, while clicking by hand 300 times introduces errors and burns hours; (2) they ask for "a record of what was deleted on each machine" — a script can write that output to a log file reproducibly, something a sequence of clicks in an explorer leaves undocumented.

Why it works: the scenario hits exactly the two points where the graphical interface "loses hands down": repetition at scale and the need to leave a reproducible trail.

Exercise 3. A coworker tells you: "I do not get it, on my Mac the prompt ends in %, but on the Linux server I SSH into it ends in $. Is something broken?" Explain what is going on and why it is not an error.

See solution

It is not an error: they are two different shells, each with its own traditional prompt symbol. Their Mac runs zsh — the default shell on macOS since Catalina (2019) — which by custom ends the prompt in %. The Linux server runs bash — the default shell on the vast majority of server distributions — which by custom ends the prompt in $.

Why it works: the prompt symbol reflects which shell family it comes from, not a configuration error; both are legitimate, widely used shells, just with slightly different rules and conventions.

Summary and next step

You can now explain to someone else the difference between terminal (the window), shell (the interpreter), prompt (the line waiting for you), and console (direct access to a machine) — and you can decide with judgment, not out of habit, when the terminal is the right call and when a graphical interface does the job better. Before moving on you should be able to: distinguish those four words in a new scenario, explain in one sentence why bash dominates Linux servers and zsh dominates macOS, and justify with at least two reasons when a task calls for the terminal instead of clicks.

Everything you saw here was conceptual, without yet touching a real terminal. That changes now: the logical next step is to have that window open in front of you, on your own operating system, with a real shell running inside it waiting for your first command.

Resources

GNU Bash Reference Manual — the official bash manual; useful as a reference once you start writing scripts later on.
Zsh — official site — documentation and news from the zsh project.
Apple Support — Use zsh as the default shell on your Mac — Apple's official announcement about the switch from bash to zsh on macOS.
Wikipedia — Computer terminal — historical context on why it is called "terminal" and where the word "console" comes from.
Wikipedia — Unix shell — an overview of the shell family (sh, csh, bash, zsh, fish) and how they relate to one another.

← Previous1. Introduction: the silent prerequisite of half the industry Next →3. Your terminal on macOS, Linux, and Windows (WSL)