The Shell, the Terminal and the Kernel · about 30 min

Terminal, shell and kernel

Why this matters

Almost every server, container, router and cloud machine in the world is driven by text commands. A graphical tool can only do what its designer anticipated; a shell lets you combine small programs into exactly the tool you need, and then save that combination as a script that runs at 3 a.m. without you. Before writing any of that, you need a clear picture of what is actually happening when you type a command, because almost every confusing shell behavior you will meet later (quoting, globbing, "command not found", a variable that is empty when it "should not be") comes from not knowing which program is doing what.

Three layers: terminal, shell, kernel

When you sit at a command line, three different pieces of software are cooperating:

  you  ──keys──▶  TERMINAL  ──bytes──▶  SHELL (bash)  ──system calls──▶  KERNEL (Linux)
       ◀─pixels──  draws text ◀─bytes──  runs programs ◀──results──────   hardware, processes

The terminal (or terminal emulator: GNOME Terminal, iTerm2, Windows Terminal, the web terminal in this tutor) is a program that shows a grid of characters. It sends what you type as bytes and draws the bytes it receives. It has no idea what ls means. The name comes from the physical terminals of the 1970s: a keyboard and screen wired to a big shared computer.
The shell is a program that reads lines of text, works out what you are asking for, and starts other programs to do it. Its name comes from being the outer layer around the kernel, the part you touch. The shell in this course is bash (the Bourne-Again SHell), the default on most Linux systems. Others exist (sh/dash, zsh, fish), and the last module covers the differences.
The kernel (here, Linux) is the core of the operating system. It is the only software allowed to touch hardware directly, and it manages processes (running programs), memory, files and devices. Everything else asks it for services through system calls: "open this file", "read 4096 bytes", "start a new process", "write these bytes to the terminal".

A process is a running instance of a program: the program's code plus its own memory, its open files, its current directory, its user identity. When you run ls three times, the program /usr/bin/ls stays the same file on disk, but three separate processes are created and destroyed.

What happens when you press Enter

Here is the life of one command, ls /etc, in more detail than you need today. Keep it in mind; the whole course fills in these steps.

bash prints a prompt (in this sandbox: learner@sandbox:/work$) and waits.
You type ls /etc and press Enter. The terminal sends those characters to bash.
bash parses the line: it splits it into words (ls and /etc), and performs expansions (variables, wildcards and so on; none here).
bash looks up the first word. ls is not built into bash, so bash searches the directories listed in the PATH variable and finds the program file /usr/bin/ls.
bash asks the kernel to fork: make a copy of the bash process. The copy (the child) then asks the kernel to exec /usr/bin/ls, which replaces the child's program with ls, handing it the words ls and /etc.
ls runs. It asks the kernel to open the directory /etc, read its entries, and write their names to its output, which is connected to your terminal.
ls exits with a small number, its exit status (0 means success).
bash, which was waiting for the child, collects the status, and goes back to step 1.

That fork-then-exec pattern is how every external program on Unix is started. It explains a lot of later surprises; for instance, a program cannot change the current directory of the shell that started it, because it is running in a separate process.

Your first commands

Open the shell for this lesson and type along. Lines starting with $ are what you type (do not type the $); the other lines are output.

$ echo Hello
Hello
$ date
Sun Nov  1 14:03:12 UTC 2026
$ whoami
learner
$ pwd
/work
$ hostname
sandbox

echo prints its arguments back. It sounds useless; you will use it constantly.
date prints the current date and time (your output will differ).
whoami prints the name of the user you are running as. In this sandbox that is learner, an ordinary user with no administrator rights.
pwd (print working directory) shows which directory your shell is "in". Every process has a current directory; relative file names are looked up from there.
hostname prints the machine's name. Yours is a container called sandbox.

Now make something:

$ mkdir first
$ ls
first
$ echo 'Hello, shell' > hello.txt
$ ls
first  hello.txt
$ cat hello.txt
Hello, shell

mkdir first (make directory) creates a directory called first in the current directory.
ls (list) shows what is in the current directory.
echo 'Hello, shell' > hello.txt: the > is not part of echo. It tells bash, before it starts echo, to connect echo's output to the file hello.txt instead of the terminal. bash creates (or empties) the file, then echo writes into it without knowing the difference. This is called redirection; it gets a whole module later. The quotes keep Hello, shell together as one argument and stop bash from treating the comma or anything else specially.
cat hello.txt prints the contents of a file.

Notice that successful commands like mkdir print nothing at all. Unix tradition: silence means success. Errors are reported:

$ mkdir first
mkdir: cannot create directory 'first': File exists
$ cat nope.txt
cat: nope.txt: No such file or directory

Error messages almost always have the form program: what: why. Read them; they are usually exactly right.

The prompt and the command line editor

bash's line editor gives you a few keys worth learning on day one:

Key	Effect
Up / Down arrows	step through previous commands (your history)
Tab	complete a command or file name; press twice to list choices
Ctrl-C	abandon the current line, or interrupt a running program
Ctrl-A / Ctrl-E	jump to the start / end of the line
Ctrl-R	search history backwards: type part of an old command
Ctrl-L	clear the screen (same as the `clear` command)
Ctrl-D	on an empty line: "end of input"; the shell exits

Tab completion is not just a convenience: it prevents typos in file names, and if Tab does not complete a name, that tells you the file is not where you think it is.

Note: This sandbox is a throwaway container with no network and no administrator (root) access. Your lesson workspace /work is kept between visits; everything else resets. You cannot damage anything, so experiment freely.

Common mistakes

Typing the $. In documentation $ marks the prompt. If you type it, bash tries to run a command whose name starts with $, and you get something odd like bash: $: command not found.
Misspelling a command. ecoh hi gives bash: ecoh: command not found. bash found no builtin, function or program named ecoh in any PATH directory. The message comes from bash, not from a program, because no program was ever started.
Missing spaces. echo'Hello' is one word to bash, echoHello after quote removal, so you get command not found. Spaces separate the command from its arguments.
Expecting confirmation. mkdir succeeding silently is normal. Use ls to see the result.
A command that "hangs". cat with no file name waits to read from the keyboard. Press Ctrl-D to end its input, or Ctrl-C to interrupt it.

Exercises

The two quizzes check the mental model; the two tasks happen in the sandbox shell. Task checks look at the files in /work, so the files are what matter, not the exact commands you typed.

Recap

The terminal draws text, the shell (bash) interprets command lines and starts programs, and the kernel does the actual work of running processes and touching files and hardware.
A process is a running program with its own memory, current directory and identity.
bash starts an external program by forking a copy of itself and having the copy exec the program.
Commands: echo, date, whoami, pwd, hostname, mkdir, ls, cat; > file saves output into a file.
Silence means success; errors look like program: object: reason.

Going further: run ps to see the processes in your sandbox, and echo $0 to see the name of your shell. Try ps -f and find bash and the ps process itself; the PPID column shows which process started which.

Exercises

Exercise 1 · quiz

Who reads the line?

You type ls /etc and press Enter. Which program reads that line of text, splits it into words and decides which program to start?

The terminal (emulator)
The shell (bash)
The kernel (Linux)
The ls program itself

Answer

The shell (bash)

The shell. The terminal only passes your keystrokes along and draws whatever text comes back. The kernel never sees the text ls /etc as a command line at all: it only receives a request from bash to start the program /usr/bin/ls with the arguments ls and /etc. And ls is started after bash has already split the line, so it receives ready-made words.

Exercise 2 · quiz

Who does the real work?

Which statements are true? Select all that apply.

Only the kernel can create a new process or read a file from the disk.
bash talks to the disk hardware directly when you run cat notes.txt.
When a command finishes, bash prints a new prompt and waits for the next line.
Closing the terminal window has no effect on the shell running inside it.

Answer

Only the kernel can create a new process or read a file from the disk.
When a command finishes, bash prints a new prompt and waits for the next line.

Programs, bash included, run in user space and must ask the kernel, through system calls, for anything that touches hardware or other processes: open a file, read bytes, start a process. cat asks the kernel to open and read notes.txt; it never drives the disk itself. And closing the terminal does matter: the kernel tells the shell its terminal went away (a signal called SIGHUP) and the shell normally exits. You will meet signals properly in a later module.

Exercise 3 · task in a shell

Your first two commands

Open the shell for this lesson. You start in /work, your workspace for this lesson.

Create a directory named first with mkdir.
Create a file named hello.txt (in /work, not inside first) that contains exactly the line Hello, shell using echo and >.

Then press Check.

Hint 1

mkdir first creates the directory. Run ls afterwards to see it.

Hint 2

echo 'Hello, shell' prints the text; adding > hello.txt sends it into a file instead of the screen.

Reference solution

mkdir first
echo 'Hello, shell' > hello.txt

Exercise 4 · task in a shell

Who and where are you?

In the shell, find out your user name with whoami and save its output in a file named me.txt. Then save the output of pwd (the directory you are in) in a file named where.txt. Both files belong in /work.

Hint 1

Run whoami on its own first and look at what it prints.

Hint 2

whoami > me.txt writes that same text into the file. Do the same with pwd.

Reference solution

whoami > me.txt
pwd > where.txt