~/tutorials/029-two-results-that-should-match.md

029: Two results that should match

The sharpest instrument in this tier is also the newest command: diff compares two files, and a comparison between two things that should be identical is how you find the thing that drifted. This lesson is the whole technique in four moves.

The tool, and its honesty

diff ~/tutorials/004-first-scan.md ~/tutorials/004-first-scan.md

diff: these two files are identical, line for line

The command says what it is: a line-by-line positional comparison, not a real diff algorithm, and it announces its count rather than pretending to craft. That honesty is the site's style and it is the right introduction, because the real diff you run at home is one of the oldest tools alive and deserves the respect of knowing what it actually compares.

Two files that should have matched

diff ~/news/2026-09-10-aws-security-agent-bucket-ownership.md ~/news/2026-09-10-mikrotik-routeros-privilege-escalation.md

diff: 30 line(s) differ, compared line by line
  2  - title: A predictable bucket name was taken as proof of ownership
       + title: A RouterOS flaw let a login raise its own permissions

Two files, same date, same shape, same length class: everything about their index entries says sibling, and the diff says thirty lines apart. The first differing line is the title, the second is the source, the third is the class. Three lines in, you know these are different stories that happened to share a date, and you know it from evidence rather than from reading both files end to end.

That is the move: when two things should match, the first differing line is the diagnosis. Read the diff's head, not the files.

Where should-match lives

The technique's natural homes, all of them yours one day:

• Two scans of the same host, a week apart. Should match. The diff is your change log, and an unexplained line in it is an incident or an undocumented operator, and either is a finding.
• Two exports of the same zone. Should match. DNS drift is the quietest way a domain stops being what its owner thinks.
• Two copies of a config, one from the backup, one from the machine. Should match. The line that drifted is the change somebody made at 2am and the reason this comparison exists.
• Two lessons the site calls twins, like the two board lessons:

diff ~/tutorials/003-the-board.md ~/tutorials/010-the-board.md

Forty-seven lines differ, and the twins were never twins: 003 is about what a point means, 010 is about the machinery underneath. Same topic, different depth, and the diff caught what the naming pattern hid. Index entries lie quietly, and this is the check that hears them.

The should in should-match

Two results should match only when they measure the same thing at the same time, which is lesson twenty-two's rule arriving again from a new angle. A diff between mismatched measurements is noise dressed as a finding: scanning a host Monday and Thursday and diffing the scans measures time, not drift, if the host updates nightly. Name the should before you run the comparison, or the diff will happily prove whatever you brought to it.

Try it

Each of these has one answer, and the shell gives it to you. Check yourself.

1. Diff the two same-day news files and read the first three differing lines only. What are the two stories, and how few lines did it take to know?
2. Diff the two board lessons. Say in one sentence why they differ so much more than the news pair despite looking like twins from their titles.
3. Diff any lesson against itself and read the answer. Then say what the identical answer is worth as the first command of any comparison session.
4. On your own machine, snapshot something today, anything, and diff it against the same capture next week. The discipline is the deliverable, and the first unexplained differing line is the reward.

The tree changes and lessons change with it. The diff of any two files today is the current truth about both.