Terminal, Shell and Program: Three Things People Call the Terminal

Part I · Module 1 · Chapter 1.3 · Terminal, Shell and Program

1. Three Components, Not One

When you run a command, three separate pieces of software take part:

1. The terminal — the thing that draws text on your screen and collects what you type.
2. The shell — the program from Chapter 1.2 that reads your line, interprets it, and arranges for something to run. Bash, here.
3. The command — the program the shell started on your behalf. ls, grep, a compiler, a simulator.

They are three programs. On a remote machine, they are not even all on the same computer. The habit of treating them as one object is the single most common reason beginners cannot say where a problem lives.

2. The Terminal: a Text Device, Nothing More

A terminal does exactly two things: it displays characters sent to it, and it sends the characters you type to whatever program is attached to it.

That is the entire job. It does not know Bash exists. It does not know what a command is. It has never heard of ls. It moves characters in two directions.

The name is historical and the history explains the design. A terminal was once a physical device — a keyboard and a screen on a desk, wired to a shared computer in another room. The terminal had no idea what you were typing; it sent keystrokes down a wire and painted whatever characters came back. What you use today is a terminal emulator: a program that imitates that device in a window. GNOME Terminal, Konsole, xterm, Windows Terminal, iTerm2, and the terminal pane inside an editor are all terminal emulators.

What the terminal is genuinely responsible for:

• drawing the characters, including the colours and bold that programs request through special character sequences;
• the window size, in rows and columns, and telling the system when you resize it;
• scrollback — the history of text that has scrolled off the top, which belongs to the terminal and to nothing else;
• copy and paste;
• turning your keystrokes, including Ctrl-C and Ctrl-D, into characters or signals sent onward;
• the font. A terminal's font is a terminal setting, which is why the same server looks different from two different laptops.

What the terminal is not responsible for: anything to do with the meaning of what you typed.

3. The Shell: the Only Part That Understands Your Syntax

Chapter 1.2 covered this, so only the division of labour matters here. The shell:

• prints the prompt;
• collects the line, with editing and history, so arrow keys and Ctrl-R do something useful (Chapter 1.8);
• applies its own language rules to the finished line — splitting it into words, expanding special characters;
• decides what the first word names, and starts it;
• waits, then takes the status back and prints a new prompt.

Everything in the list is about meaning. The shell is the only one of the three components that has an opinion about syntax. *, quotes, | and > mean something to the shell and to nothing else in the chain.

4. The Command: Where the Actual Work Happens

The third component is the program the shell started. It:

• receives a list of words from the shell — already split and expanded;
• interprets those words according to its own rules, which is why -r means something different to rm, grep and cp (Chapter 1.5);
• does the work, asking the kernel for files, memory and time;
• writes its own output and its own error messages;
• finishes, and hands back a status number.

A program's output goes to the terminal, so it appears in the same place the shell's prompt appeared. That shared destination is exactly why the three get confused. Same window, three different authors.

5. One Command, End to End

Figure 1 follows a single ls -l from keystroke to prompt. Time runs downward; each arrow is one component handing something to another.

Two details in that figure are worth stating explicitly.

The echo of your own typing is the shell's doing. You see what you type because the shell sends it back to the terminal to be displayed. This is why a password prompt can hide what you type: the program collecting the password simply stops echoing. Nothing about the terminal changed.

The program writes to the terminal, not through the shell. Once ls is running, its output is its own. The shell is waiting, not relaying. Module 12 is where you learn to intercept that output and send it somewhere else, and it is only possible to understand that module if you already know the output was never the shell's to begin with.

6. The Proof: a Remote Login

Everything above could be a convenient story. Here is the observation that makes it unavoidable.

When you connect to another machine, the terminal stays on your laptop and the shell runs on the remote machine. They are on different computers, possibly in different countries. They cannot be the same program.

ssh engineer@build-server

engineer@build-server:~$ hostname
build-server

Your window is on your laptop; hostname ran on build-server and reported that machine's name. The characters you typed travelled over the network to the shell there. The shell's prompt and hostname's output travelled back and were painted by your local terminal.

This also explains things that otherwise look inconsistent:

• Your local font and colours still apply. They are terminal settings, and the terminal is local.
• Your local scrollback still works. Scrollback belongs to the terminal.
• The prompt changed. The prompt is printed by the remote shell, which has its own configuration.
• A graphical program will not simply appear. A terminal carries text. A waveform viewer is not text, so showing one from a remote machine needs something beyond the terminal — which is why remote graphical display is configured separately in engineering environments, and why "my terminal works but the viewer will not open" is a sensible sentence rather than a contradiction.

7. Who Printed That? A Diagnostic Table

This is the chapter's practical output. For each thing you see, exactly one component is responsible.

Notice the pattern in the error messages. The shell prefixes its complaints with its own name — bash: — and a program prefixes its complaints with its name — ls:. That prefix is a convention, and it is the cheapest available clue about which component is talking to you.

8. A Second Proof: a Shell Inside a Shell

One more observation, which takes ten seconds and settles the matter.

bash

engineer@server:~$ bash
engineer@server:~$ exit
exit
engineer@server:~$

You just started a second shell. It is a program, so of course you can run it; nothing stops you. The new shell printed its own prompt in the same window, read your exit, finished, and the first shell printed its prompt again.

One window. Two shells, one after the other. If the window and the shell were the same thing, that sequence would be impossible.

This also previews something real: shells nest, and so a script you run is generally a different shell from the one you typed in. That fact is the whole reason behind a rule you will meet in Module 10 — that a script cannot change the directory of the shell you launched it from — and the reason Chapter 1.7's treatment of cd is not a curiosity.

9. Misconceptions

"The terminal runs my commands." It cannot. It has no idea what a command is. It transports characters; the shell interprets them; a program does the work.

"The terminal is Bash." Shown false twice above — by SSH, where they are on different machines, and by running bash inside your window.

"Everything in that window came from the shell." Most of it did not. Once a program is running, its output is its own and goes straight to the terminal.

"Closing the window just closes a window." Closing the terminal ends the session: the shell inside it exits, and programs it started usually stop too. This is real, and it is why a long-running job needs deliberate handling. The mechanism is signals, which Module 7 teaches; the practice is in Module 30. Do not improvise a fix now — know that the question exists.

"Ctrl-C is a Bash feature." Ctrl-C is a key the terminal turns into a request to interrupt, which the kernel then delivers to the running program. The program decides what to do about it — which is why Ctrl-C sometimes appears to do nothing. Module 7 covers signals properly.

10. Check Your Understanding

Question 1. You see bash: vcs: command not found on a compute server. Did a program start and fail, or did nothing start at all? Which component produced the message?

Question 2. You SSH to a server, change your laptop's terminal font, and the remote session's text changes appearance. Which component did you reconfigure, and why did the change apply to a remote session?

Question 3. A colleague says "the terminal ate my output." You suspect the output was produced normally but has scrolled away. Which component owns scrollback, and which owns the output itself?

Question 4. Name the three components and, for each, one thing it is solely responsible for.

11. Remember

• Three components, three jobs. The terminal moves characters. The shell interprets meaning. The program does the work.
• The terminal understands no syntax at all. Patterns, quotes, pipes and redirection mean something to the shell and to nothing else in the chain.
• The prompt is the shell's. So is the echo of your own typing — which is why a password prompt can simply stop echoing.
• A running program writes straight to the terminal. The shell is waiting, not relaying. Module 12 only makes sense once that is clear.
• SSH proves the separation: terminal on your laptop, shell on the server, and they are plainly not the same program.
• Shells nest. Running bash inside your window gives you a second shell in the same terminal — the fact behind Module 10's rule that a script cannot change your shell's directory.
• Read the message prefix. bash: means nothing ran. A program's own name means it ran and then complained.

With the three components separated, the next chapter sits you in a real session and answers the first three questions you should ask on an unfamiliar machine: where am I, who am I, and which machine is this?