Table of Contents
Understanding the Shell
At the command line in Linux, you are not talking directly to the kernel or the operating system. You are talking to a program whose job is to interpret what you type and make things happen. That program is called a shell.
The Shell’s Role
A shell is:
- A command interpreter: it reads what you type, parses it, and runs the appropriate program or built‑in command.
- A text-based user interface: it provides prompts, accepts input, and prints output.
- A scripting environment: it lets you automate tasks by writing scripts in the shell’s built‑in language.
Conceptually, a shell sits between you and the kernel:
- You: type a command (e.g.
ls). - Shell: interprets the command, looks up the program, prepares arguments, sets up input/output.
- Kernel: actually executes the program and provides access to hardware and system resources.
- Shell: regains control when the program finishes and shows you a prompt again.
The shell is not the terminal emulator itself (like GNOME Terminal, Konsole, etc.). The terminal displays text and handles keyboard input; the shell runs inside that terminal.
Interactive vs Non‑Interactive Use
Shells can run in two main modes:
Interactive shells
You use these directly:
- You get a prompt like
$or#. - You type commands one by one.
- The shell responds immediately.
Typical use:
- You open a terminal window.
- Log in over SSH.
- Use a TTY (text console) on the machine.
In an interactive shell, features like command history and tab completion are active (covered in other chapters).
Non‑interactive shells
These do not wait for your input; instead, they run commands from a file or from another program:
- Running a shell script:
bash myscript.sh - Using
sh -c 'some command' - Scripts that start with a shebang line, for example:
#!/bin/bash
echo "Hello from a script"In non‑interactive mode, the shell mostly just executes what is given, without interactive niceties.
Types of Shells
There are multiple shell implementations on Linux. Each is a program with its own features and scripting “dialect”, but all serve the same basic role.
Common shells include:
sh– the original Bourne shell (historical; often a symlink to another shell such asbashordashtoday).bash– Bourne Again SHell, widely used default on many distributions.zsh– Z Shell, feature-rich and popular among power users.fish– Friendly Interactive SHell, with a user-friendly, modern feel.dash,ksh, etc. – other less common or specialized shells.
Shell choice affects:
- Available features (e.g. advanced completion, prompt customization).
- Scripting syntax and compatibility.
- Performance in some cases (e.g. small, fast shells for scripts).
The detailed comparison of bash, zsh, and fish is covered separately; here it’s enough to know that “the shell” is a type of program, and there are several variants you can choose from.
Login vs Non‑Login Shells
Shells are also distinguished by how they are started:
Login shells
Started when you log into the system:
- At a text console (TTY).
- Over SSH.
- Sometimes when you start a terminal that is configured to run a login shell.
Login shells typically read system and user startup files (like /etc/profile and ~/.profile or ~/.bash_profile, depending on the shell) to set up your environment.
Non‑login shells
Started inside an existing session, for example:
- Opening a new terminal tab/window (often configured as non‑login).
- Running
bashfrom within an existing shell.
These usually read different initialization files (like ~/.bashrc for bash) appropriate for interactive use.
Details of shell configuration files are discussed elsewhere, but the key point here is: how your shell starts affects what configuration files it reads and therefore what environment you get.
Built‑ins vs External Commands
When you type a command, the shell may:
- Run a built‑in command:
- Implemented inside the shell program.
- Does not require starting a new process.
- Examples (names vary slightly by shell):
cd,echo,pwd,export,alias. - Run an external command:
- A separate executable file in the filesystem.
- The shell finds it via the
$PATHenvironment variable (details in later chapters). - Examples:
/bin/ls,/usr/bin/grep,/usr/bin/python.
The shell decides which one to use by:
- Checking if the name matches a built‑in.
- Then checking for aliases or functions.
- Finally searching for an external program in directories listed in
$PATH.
You can see how a shell resolves a command (for example, in bash or zsh):
type lstype cd
Understanding this resolution process is essential when commands don’t behave as expected (e.g. an alias overrides an external command).
The Shell as a Programming Language
Besides running single commands, a shell includes a full (though limited) programming language. This allows:
- Combining commands with operators like
;,&&,||, and|. - Variables to store and reuse values.
- Conditionals and loops to control what runs when.
- Functions to group reusable logic.
Example of a simple shell one-liner:
[ -d mydir ] && echo "Directory exists" || echo "Directory missing"This illustrates that the shell is not just a “command runner”; it has syntax and rules that are interpreted before your commands reach the kernel.
Full shell scripting is handled in a later part of the course; here, the key point is that the shell is also a scripting environment.
The Shell and the Terminal
It’s common to confuse the shell with the terminal:
- Terminal emulator (e.g. GNOME Terminal, Konsole, xterm):
- Graphical program that provides a window, scrollback, text rendering, and keyboard handling.
- Can run any text program inside it, not just a shell.
- Shell (e.g. bash, zsh, fish):
- Command interpreter program that runs inside the terminal.
- You can replace it without changing the terminal emulator.
You can even run a shell inside another shell (for example, starting bash from a zsh session) because from the outer shell’s point of view, the inner shell is just another program.
Why the Shell Matters
For Linux users and administrators, the shell is important because it:
- Provides precise control over the system.
- Enables automation of repetitive tasks.
- Works consistently over SSH and in environments without a graphical desktop.
- Is often the only available interface on servers and in recovery situations.
As you progress, you’ll move from simply typing commands into the shell to using it as a powerful, scriptable interface to the entire system.