The command line is the part of Linux people meet first and the part that explains least. Underneath it sits one small model: processes with private memory, numbered descriptors standing for anything you can read or write, one tree of files, and a kernel you enter only through a checked door. Almost everything that reads as bizarre — a deleted file still filling the disk, a process that will not die — falls out of that model. Learn the model and the commands stop needing to be memorised.
Each chapter opens with the short version. Tap one to read the detail.
One door into the kernel
~2 min
Your program cannot touch hardware or another process's memory directly; it asks the kernel through one checked entry point. A library call is not a kernel call, and errno means nothing after a call that succeeded.
What a process is, and how to look at one
~2 min
A program is a file; a process is one running instance with its own memory and number. The trap is judging one by how busy it looks: a task in uninterruptible sleep ignores SIGKILL, and load average counts tasks waiting on disk.
How a program becomes a running process
~2 min
Linux does not start a program: a process copies itself with fork, and the copy replaces itself using exec. Nothing new is created — the PID is unchanged, which is why redirection works on programs that know nothing about your shell.
Signals, and why some processes ignore them
~2 min
A signal interrupts a process and runs a handler or a default action. SIGKILL is not a stronger SIGTERM but a mechanism the target never sees, and blocked standard signals do not queue — repeated deliveries collapse into one.
Memory you do not have until you touch it
~2 min
Every process gets its own virtual address space, so one cannot reach into another. Two numbers are misread constantly: reserved address space is not memory consumed, and near-zero free memory is usually healthy rather than full.
Descriptors: one interface for everything
~2 min
Files, pipes, sockets, terminals and devices are read and written through the same numbered handles. The mistake is assuming two handles on one file are independent: a *duplicate* shares its offset, a second open gets its own.
Names, inodes, and what "saved" means
~2 min
A file's metadata lives in its inode; its name does not. Two assumptions cost people days: that deleting a file frees its space, and that a successful write is saved rather than merely cached.
One tree, and who is allowed to walk it
~2 min
Everything hangs off a single /, and another disk appears at a mount point rather than a drive letter. Two rules cause most surprises: on a directory execute means traverse, and deleting is a permission on the *directory*.
From power-on to process 1, and what boxes a process in
~2 min
The kernel starts exactly one user-space process and every other descends from it. Two wrong assumptions: that enabling a service starts it, and that a container is a virtual machine rather than a process with a narrowed view and a budget.
What the shell is actually doing
~2 min
The shell is an ordinary program that arranges a process and gets out of the way — which explains its three classic surprises: redirections apply left to right, a script cannot change the shell that ran it, and buffering changes without a terminal.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.