In 1969, Ken Thompson sat down at a PDP-7 computer at Bell Labs and wrote the first version of Unix in three weeks while his wife and infant son were on holiday. He wanted a system where small programs could be combined to accomplish large tasks - not a monolith, but a toolbox. The interface he built to glue those tools together was the shell. More than fifty years later, you are still using a direct descendant of that idea every time you open a terminal window.
Before you type a single command, it is worth separating two things that people constantly conflate. The terminal is the window - the rectangle of black or dark space on your screen that accepts text and displays text back. The shell is the program running inside that window. The terminal is the cockpit glass. The shell is the flight computer that actually decides what to do with your inputs.
Why This Distinction Matters
The shell you use determines your syntax, your autocomplete behaviour, and which scripts will run correctly on your machine. The most common shells are Bash, which has been the default on Linux systems for decades, and Zsh, which replaced Bash as the default on macOS in 2019. They are close enough that most commands work identically in both - but when they diverge, knowing which shell you are in tells you which manual to check.
To find out which shell is currently running, type:
echo $SHELL
That command asks the shell to print the value of an environment variable called SHELL. The dollar sign tells the shell that what follows is a variable name, not literal text. The response will be something like /bin/zsh or /bin/bash.
The Loop That Never Stops
The shell operates on a cycle that runs continuously from the moment you open the terminal to the moment you close it. It is called the Read-Eval-Print Loop, or REPL.
The shell reads what you type. It evaluates the input - parsing it, finding the program you named, and preparing any arguments you passed. It prints the result to the screen. Then it loops back to the prompt and waits for you again.
The prompt itself - usually a $ for regular users and a # for the root administrator - is not decoration. It is the shell signalling that the previous command finished and it is ready for a new one. If the prompt disappears and does not return, the shell is still running a command. Pressing Ctrl+C sends an interrupt signal that cancels the current operation and returns the prompt.
Key Point: The shell processes one command at a time through a read-evaluate-print cycle. The prompt is your signal that the previous operation completed. If you do not see the prompt, the shell is still working - or it is waiting for input you have not provided yet.
The Grammar of a Command
Every command you type follows the same structure: the name of the program, followed by options, followed by arguments. In the command ls -l /home/user, the program is ls, the option is -l, and the argument is /home/user.
Options modify how a program behaves. They come in two flavors. Short options are a single letter preceded by one hyphen: -l, -a, -h. Long options are words preceded by two hyphens: --all, --human-readable. Short options can usually be chained together - ls -la is the same as ls -l -a - which is why experienced users write them that way. Long options cannot be chained and must each have their own double-hyphen prefix.
Arguments are what the command acts on. Some commands require them. cd without an argument takes you to your home directory. cat without an argument reads from your keyboard until you press Ctrl+D. rm without an argument does nothing and returns an error - which is the right behaviour, given that rm deletes files.
The Kernel Is Behind the Curtain
When you run a command, the shell is not doing the actual work itself. It hands the request to the kernel - the core of the operating system that manages memory, processes, and hardware. The shell is the receptionist. The kernel is the facility doing the work.
This matters for one practical reason: some operations require kernel-level permissions that your regular user account does not have. When you try to modify a system file and get a "Permission denied" error, you are not hitting a shell limitation. You are hitting a kernel enforcement boundary. The tool for crossing that boundary is sudo, which you will meet in Lesson 5.
Key Point: Bash and Zsh are the two shells you will encounter most often. They share almost identical syntax for basic operations. echo $SHELL tells you which one you are using right now.