CliBookfield notes for the terminal
Volume one · Orientation

A field guide to the command line, written to be read.

Most terminal references read like a phone book. This one reads like a set of margin notes: what a tool is actually for, how its syntax wants to be read, and where the authoritative documentation keeps its latest edition.

Compiled by the CliBook editors Reviewed continuously Edition: 2026

I.Getting oriented

The terminal rewards patience. Unlike a graphical application, a command-line utility tells you almost nothing until you ask — and everything once you do. The habit that separates comfortable users from frustrated ones is small: learn one verb at a time, keep notes, and read the manual page before the forum thread.

These pages exist to give you the orientation that manuals assume you already have. Each entry below describes a widely used utility in plain language, then points you toward its official documentation so you can go deeper from a solid footing.

“The command line is a conversation. The manual is the other participant’s biography.”

II.The reading list

Twenty chapters, arranged the way a syllabus is — from the utilities you meet on day one to the ones you grow into.

Git versioning

The record-keeper for source code. Its mental model — snapshots joined by references — explains nearly every subcommand once it clicks.

Canonical text: git-scm.com/docs

Docker containers

Portable runtimes for software. Worth reading as two ideas: an image (the blueprint) and a container (the running instance built from it).

Canonical text: docs.docker.com

Node.js & npm javascript

A runtime and its librarian. Most confusion dissolves once package.json is read as a manifest rather than a config file.

Canonical text: nodejs.org/docs

Python & pip python

An interpreter and its package courier. Virtual environments are the chapter people skip and later reread first.

Canonical text: docs.python.org

kubectl orchestration

The steering wheel of a Kubernetes cluster. Its verbs follow a grammar: resource, then intention, then constraints.

Canonical text: kubernetes.io/docs

curl transfer

A conversation with servers, in one verb. Flags read like punctuation: silent, verbose, redirect-following.

Canonical text: curl.se/docs

ssh remote

A private corridor to another machine. Its config file is the most under-read chapter in the whole library.

Canonical text: man.openbsd.org/ssh

rsync sync

A courier that only ships what changed. The dry-run flag is the difference between confidence and regret.

Canonical text: rsync.samba.org/documentation

III.How to read this library

  1. Start with purpose. Before the first command, be able to finish the sentence: “This tool exists because…” Every chapter opens with exactly that.
  2. Read syntax as grammar. git <verb> <object> — once the pattern is visible, unfamiliar subcommands stop looking foreign.
  3. Consult the primary source. Each chapter ends with a pointer to the project’s own documentation. That is where versions and caveats live; this site is the map, not the territory.
  4. Keep your own margins. Notes you write beat notes you find. Skim here, then annotate your own copy of the manual.

IV.Questions readers send us

Is this an official documentation site?
No. CliBook is an independent reading companion. Every entry links to the project it describes; the projects themselves are the authorities on their own syntax, defaults, and behavior.
Do you host any software?
No software is stored on this domain. We describe utilities and point to their official documentation; acquisition always happens on the project’s own terms, through their channels.
Which platforms do you cover?
Utilities that run on macOS, Linux, and the Windows terminal. Where behaviour differs between platforms, the chapter says so.
How current are the entries?
Entries describe concepts and reading order, which age slowly. For version-specific detail — flags, defaults, deprecations — we deliberately defer to the canonical documentation.