What a Shell Is, and Why Bash

Part I · Module 1 · Chapter 1.2 · What a Shell Is, and Why Bash

1. The Problem a Shell Solves

Chapter 1.1 established that the kernel owns the machine and that userland is full of ordinary programs. That leaves an obvious gap: how does a human start one of those programs, tell it which files to work on, and get its output back?

Something has to sit between a person and a few thousand executable files. That something needs to:

• accept a line of text from a keyboard;
• work out which program the line is asking for;
• work out which files and options the line is asking about — possibly several hundred files, named by a pattern rather than individually;
• ask the kernel to run the program with exactly those inputs;
• show you what came back, and tell you whether it worked;
• then be ready for the next line.

That is a shell. The name is apt: it is the outer layer you touch, wrapped around the system you cannot touch directly.

2. The Shell Is an Ordinary Program

Before anything conceptual, settle a concrete fact. Bash is a file on disk, with a size and a version, exactly like ls or a compiler.

ls -l /bin/bash

-rwxr-xr-x 1 root root 1396520 Mar 31  2024 /bin/bash

bash --version

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Nothing in that output suggests a component of the operating system. It is a program, it has a version, and a different machine may have a different one — which is why Module 21 has a chapter on portability and why "it works on my machine" is a real category of bug rather than an excuse.

This also means something liberating: the shell has no privileged relationship with the kernel. It asks the kernel for things using the same mechanisms any program uses. It is not inside Linux; it runs on Linux.

3. The Loop: Read, Interpret, Decide, Run, Report

Here is what actually happens between pressing Enter and seeing the next prompt. Five steps, in order, every single time.

Taken one at a time:

1. Read. The shell reads an entire line before doing anything with it. Nothing happens while you are still typing; Enter is what starts the work.

2. Interpret. The shell applies its own rules to that text. It splits the line into words at whitespace, and it looks for characters that mean something to it rather than to you. This step rewrites the line. Section 4 proves it.

3. Decide. With a first word in hand, the shell works out what that word names. It may be something the shell implements itself, or a program file somewhere on the machine. Chapter 1.7 is entirely about this decision.

4. Run. The command does the actual work. If it is a program, the kernel starts it as a separate process and it reads its own options, opens its own files and writes its own output. The shell is not involved in any of that; it waits.

5. Report back. The command finishes and hands back a small number saying whether it succeeded. The shell takes that number, keeps it available, and prints a new prompt. Module 11 is built entirely on that number.

4. Proof That Step 2 Exists

Assertions about interpretation are cheap. Watch it happen.

echo is a command that does exactly one thing: it prints the words it is given, separated by single spaces. Give it ordinary words and it is unremarkable:

echo hello    there

hello there

Two observations already. The output has one space where you typed four — because the shell split the line into the words echo, hello and there, and echo was handed three separate words with no record of the spacing between them. The spacing was consumed in step 2 and never reached the program.

Now something stranger. Go to a directory with a few files in it and run:

echo *

notes.txt report.log run.sh

echo prints the words it is given, and it printed three filenames. But you did not type any filenames.

The explanation is step 2. The shell saw *, recognised it as a character that means something to the shell, and replaced it with the names of the files in the current directory. By the time echo started, its words were notes.txt, report.log and run.sh. It had no idea a * was ever involved.

Deliberately deferred. The * above is filename expansion, and this chapter stops at having seen it. Module 3 teaches the patterns properly, and Module 9 teaches the complete, ordered list of everything the shell expands and how quoting controls each one. The purpose here is only to establish that the step exists, because it is almost impossible to learn the later rules while believing your line goes through untouched.

5. The Shell Decides What to Run, Too

Step 3 deserves its own note, because beginners usually assume the shell contains the commands.

It does not — mostly. Most commands are separate programs: files on disk, each with its own author, version and option set. When you type one, the shell finds the file and asks the kernel to run it.

A small number of commands are different: the shell implements them itself, inside its own process. cd is the famous one, and the reason it must work that way is genuinely interesting rather than an implementation accident.

That is Chapter 1.7, and it is deliberately not compressed into a paragraph here. For now, the useful shape is: the shell decides what kind of thing your command is before anything runs, and the two kinds behave differently in a way you can observe.

6. Why Bash, and What the Alternatives Are

There is no single shell. There is a family, with shared ancestry and mostly shared grammar.

The lineage. The Bourne shell, sh, arrived on Unix in the late 1970s and defined the basic grammar — words, redirection, pipelines, variables, control flow — that every shell in this family still uses. Bash is the GNU project's shell, first released in 1989, written as a free replacement for sh with substantial additions. Its name is a joke about that: Bourne-Again SHell.

Why Bash in particular. Three reasons, in order of how much they matter to you:

1. It is the default on most Linux distributions, which means it is the shell you get when you log into a server without asking for anything special, and the shell most existing scripts assume.
2. It is the common denominator in engineering environments. Automation written in Bash runs on essentially any Linux machine you will meet, which is exactly what you want from a flow script.
3. It is a complete scripting language, not only an interactive prompt — the same grammar you type by hand also runs unattended.

The alternatives you will actually encounter. Worth recognising, not worth learning yet:

That last row of the table is the one with real consequences in semiconductor work. Established EDA environments sometimes still use csh-family shells for their setup scripts, and that is not a Bash dialect — it is a different language with different variable syntax and different control flow. Part II treats this where it belongs, under environment setup. For now: when someone hands you a setup script, it is reasonable to check which shell it is written for before assuming it is yours.

7. Typing It vs Writing It Down

One more distinction, briefly, because it shapes the whole course.

The same Bash is used two ways. Interactively, you type a line, see the result, and decide what to do next. Non-interactively, Bash reads lines from a file and executes them without a human present.

The grammar is identical. The five steps in Figure 1 are identical. What changes is that nobody is watching — so a mistake that you would have noticed and corrected at a prompt will instead run to completion unattended. That is why Part I spends a whole module (Module 20) on making scripts fail loudly rather than quietly.

Module 15 is where you write the first script. Everything until then is the same language, learned where you can see each result immediately.

8. Misconceptions That Cost Real Time

"The shell runs my commands." It arranges for them to run. For most commands, a separate program does the work in its own process, with its own options, its own output and its own bugs. This matters the moment something misbehaves: if grep rejects an option, that is grep's decision, and reading Bash documentation will not help.

"The shell is the black window." The window is a different program. Chapter 1.3 is entirely about separating those two, because conflating them makes it impossible to say which one is responsible when something looks wrong.

"Whatever I type after the command name is passed through as typed." Shown false in §4. The shell splits and rewrites first. Nearly every quoting bug in existence is this misconception meeting a filename with a space in it.

"Bash is Linux." Bash is one userland program on a Linux system, per Chapter 1.1. It runs on other systems too, and a Linux system can run a different shell instead. They are independent choices.

9. Check Your Understanding

Question 1. You run echo hello world with six spaces and see one space in the output. Which of the five steps removed the spaces, and did echo ever know they existed?

Question 2. You run echo * in an empty directory and the output is a single *. Using step 2, explain why the shell might hand the program the pattern itself. (Module 9 covers the rule; the point here is to reason about which step decides.)

Question 3. A colleague says "Bash doesn't support that option." The command they ran was sort --parallel=4. Why is Bash almost certainly not the component to ask about?

Question 4. Give the five steps in order, from memory, and say which one a quoting bug lives in.

10. Remember

• A shell is a program that reads command lines, interprets them by its own rules, and arranges for commands to run. It is ordinary userland software with a file and a version.
• The loop is: read, interpret, decide, run, report back. It runs in that order, every time, for every line.
• Step 2 is the one nobody tells you about. The shell splits your line into words and expands characters that are special to it. The program receives the result, never your original text.
• echo * is the proof. The program printed filenames you never typed, because the shell replaced the pattern before the program started.
• The shell also decides what kind of thing to run — something it implements itself, or a program on disk. Chapter 1.7 takes that apart.
• Bash is one shell among several, chosen here because it is the default on most Linux systems and the common denominator for automation. sh is a standard, not a nickname for Bash; csh-family shells are a different language.
• Interactive and scripted Bash are the same language, differing only in whether anyone is watching when a mistake happens.

The next chapter separates the three things people all call "the terminal" — the window, this shell, and the program it runs — and makes it clear which of them is responsible for what.