9.1 Documentation Sources

9.1 Documentation Sources

Kali ships more than 600 security tools, and nobody memorizes them all. The Kali Linux Revealed book — and therefore the KLCP (Kali Linux Certified Professional) exam — expects you to know exactly where authoritative, offline documentation lives on a Kali system and how to search it. The classic Unix advice RTFM (Read The Fine Manual) exists because the fastest correct answer is usually already installed on your machine.

The man Page System

man pages (manual pages) are the traditional Unix reference documents, read with the man command:

man nmap

A man page follows a conventional layout. Knowing these headings helps you scan quickly under exam pressure:

• NAME — the command name and a one-line description (this is what search tools index)
• SYNOPSIS — the formal command syntax; brackets [] mark optional arguments
• DESCRIPTION — what the tool does and how it works
• OPTIONS — every flag, usually with a short and long form
• EXIT STATUS, FILES, EXAMPLES — return codes, config paths, and worked invocations
• SEE ALSO — related pages, often with section numbers like passwd(5)
• BUGS and AUTHORS — known issues and credits

man pages render in a pager (usually less), so the navigation keys are the pager's: Space/b page forward and back, /pattern searches forward, n jumps to the next match, g/G go to the top and bottom, and q quits.

The Nine Manual Sections

The manual is split into nine numbered sections, because the same word can name a command, a file, and a system call. This is one of the most frequently tested facts in this chapter:

The classic exam trap is passwd: man passwd (equivalent to man 1 passwd) documents the command that changes passwords, while man 5 passwd documents the format of the /etc/passwd file. The same collision exists for printf — man 1 printf is the shell command, man 3 printf is the C library function. When you give no section number, man walks the sections in order and shows the first match, which is why you get the command by default. Use man -a passwd to step through every matching page one after another, and whatis passwd to list which sections actually have a page.

Searching When You Don't Know the Name

If you know what you want to do but not the tool name, use keyword search:

man -k wireless
apropos wireless

man -k and apropos are equivalent: both search the whatis database — the collection of NAME-line one-liners from every installed man page — and return each page with its section in parentheses, like aircrack-ng (1). The database is built and refreshed by mandb, which is why keyword search occasionally misses a brand-new package until the database updates. The companion command whatis <name> does the reverse: it prints the one-line description for an exact page name. A useful habit during labs: run man -k on a broad keyword (e.g. man -k bluetooth) to discover Kali tools you did not know were installed.

GNU info Documents

Many GNU projects document themselves in Texinfo format, read with the info command:

info coreutils
info bash

The book recommends reading these with pinfo rather than plain info (sudo apt install pinfo, then pinfo coreutils): pinfo is friendlier to navigate and falls back to the man page of the same name when no info document exists. Note also that info manuals are English-only, unlike man pages, which can be translated. info documents are hypertext: content is organized into linked nodes with menus, and you navigate with n (next node), p (previous), u (up a level), l (last visited, like a back button), Tab to move between links, Enter to follow one, and q to quit. For tools like coreutils, bash, grep, and find, the info manual is often dramatically more complete than the man page — the man page may even say so and point you to info. On the exam, remember the distinction: man pages are single flat reference documents; info manuals are hyperlinked, tutorial-style documents.

--help Versus man

Nearly every command accepts --help (or -h), which prints a compact usage summary straight to the terminal:

ls --help
nmap --help | less

The two serve different purposes, and the exam likes to probe the difference:

This matters on Kali in particular: many offensive-security tools are upstream projects with thin or missing man pages, and some print their entire documentation when run with no arguments or with -h. When a man page comes up empty, tool --help and tool -h are your next stops, not a dead end.

/usr/share/doc/<package>/

Every Debian-format package — and Kali is Debian-based — installs documentation into /usr/share/doc/<package>/. Explore one:

ls /usr/share/doc/nmap
zcat /usr/share/doc/nmap/changelog.Debian.gz | head

The files you will see again and again:

• README — the upstream author's documentation
• README.Debian — notes from the Debian maintainer (inherited by Kali) about packaging decisions, Debian- or Kali-specific paths, and differences from upstream behavior. This file is a named exam favorite.
• changelog.gz — the upstream change history; changelog.Debian.gz — the packaging change history. Both are gzip-compressed, so read them with zless or zcat, not cat.
• copyright — the license and upstream source location; Debian policy requires it.
• NEWS.gz — user-visible upstream changes per release; NEWS.Debian.gz documents the major changes that directly concern the administrator.
• Large documentation lives elsewhere — if a package's docs are big, Debian splits them into a separate <package>-doc package that the main package recommends.
• examples/ — some packages ship sample configs or scripts here, ready to copy.

Kali-Specific Notes

A few practical pointers for Kali specifically. First, dpkg -L <package> lists every file a package installed — a fast way to discover where a tool's docs, configs, and sample files landed. Second, much of Kali's best documentation is online rather than local: kali.org/docs holds the official, continuously updated guides, and it is the right next step when local docs are stale. Third, remember that Kali's rolling-release model means package versions move fast; the local /usr/share/doc changelogs always describe the exact version installed, which makes them more trustworthy than a random blog post. Finally, do not confuse tool documentation with wordlists and payloads — resources like /usr/share/wordlists are data, not docs, though dpkg -L will show you both. When you cannot find an answer locally at all, that is the signal to move to the community resources covered in the next section.