Linux commando: diff

1. De basis

diff vergelijkt twee bestanden regel voor regel en beschrijft wat je in het eerste zou moeten veranderen om er het tweede van te maken. Die richting doet ertoe: een diff is geen neutrale lijst verschillen, het is een recept met een van en een naar.

1.1 De eenvoudigst mogelijke toepassing

Twee versies van een klein configuratiebestand:

$ diff old.php new.php
3c3
<     'host'  => 'localhost',
---
>     'host'  => 'db.internal',
5c5
<     'debug' => false,
---
>     'debug' => true,

Dit is het oorspronkelijke uitvoerformaat uit 1974, en het leest als een reeks bewerkingen:

Twee andere letters verschijnen in plaats van c: a voor regels die toegevoegd worden (add) en d voor regels die verdwijnen (delete). 7a8 betekent dus "voeg na regel 7 van het oude bestand toe wat regel 8 van het nieuwe wordt".

Je zult dit formaat zelden bewust gebruiken. Hoofdstuk 4 behandelt de twee die je echt wilt. Het is het herkennen waard, want dit krijg je als je vergeet om iets anders te vragen.

1.2 De afsluitcode is het punt

De uitvoer is voor mensen. De afsluitcode is wat diff bruikbaar maakt in een script, en die heeft drie waarden:

$ diff old.php old.php >/dev/null ; echo $?
0                                  # the files are identical

$ diff old.php new.php >/dev/null ; echo $?
1                                  # they differ

$ diff old.php nosuch.php >/dev/null 2>&1 ; echo $?
2                                  # something went wrong

Die 2 is degene die mensen vergeten. Een ontbrekend bestand, een onleesbare map of een verkeerde optie levert allemaal die code op, en een script dat "niet nul" leest als "de bestanden verschillen" meldt een verschil dat in werkelijkheid een typefout in een pad was.

if diff -q "$a" "$b" >/dev/null; then
    echo "identical"
elif [ $? -eq 1 ]; then
    echo "they differ"
else
    echo "diff itself failed"
fi

Het juiste mentale model: diff vertelt je niet dat twee bestanden verschillen. Hij schrijft de instructies op om van het eerste het tweede te maken, in een formaat dat precies genoeg is dat patch ze zonder jou kan uitvoeren.

3. Een korte geschiedenis

diff kwam halverwege de jaren zeventig uit Bell Labs, en het probleem dat het oploste was geen versiebeheer. Het was dat computers traag waren en schijven klein, en dat het verschil tussen twee versies van een bestand bewaren veel goedkoper was dan allebei bewaren.

Het deel van het verhaal dat veranderde hoe software geschreven wordt kwam later. In 1985 bracht Larry Wall patch uit, en de combinatie van beide maakte van een diff een verzendmethode in plaats van een beschrijving. Software werd verspreid door diffs naar Usenet-nieuwsgroepen te sturen, waar iedereen ze op zijn eigen kopie van de broncode kon toepassen.

De man-pagina van patch vermeldt de betrokkenen nog steeds, en een naam daarin verklaart het formaat dat je dagelijks leest:

$ man patch
AUTHORS
       Larry Wall wrote the original version of patch.  Paul Eggert removed
       patch's arbitrary limits; added support for binary files, setting
       file times, and deleting files; ...  Other contributors include
       Wayne Davison, who added unidiff support, and David MacKenzie, who
       added configuration and backup support.

"Unidiff support" is het unified-formaat. Het is het waarderen waard hoe volledig het gewonnen heeft: GitHub, GitLab, elk gereedschap voor code review en git diff zelf tonen allemaal het formaat dat aan een programma uit 1985 werd toegevoegd zodat patches in een e-mail zouden passen.

Leren een unified diff te lezen is niet een Unix-commando leren. Het is het formaat leren waarin elke code review ter wereld geschreven is.

5. Gemiddelde toepassingen

5.1 Twee mappen vergelijken

Hier houdt diff op gereedschap voor programmeurs te zijn en wordt het gereedschap voor beheerders. -r (kort voor recursive) loopt twee bomen af:

$ diff -r v1 v2
Only in v2: added.txt
diff -r v1/changed.txt v2/changed.txt
1c1
< old
---
> new
diff -r v1/inc/deep.txt v2/inc/deep.txt
1c1
< x
---
> y
Only in v1: removed.txt

Op twee echte websites is die uitvoer duizenden regels lang. Wat je vrijwel altijd wilt is er -q bij (kort voor brief), dat meldt welke bestanden verschillen zonder de inhoud te tonen:

$ diff -rq v1 v2
Only in v2: added.txt
Files v1/changed.txt and v2/changed.txt differ
Files v1/inc/deep.txt and v2/inc/deep.txt differ
Only in v1: removed.txt

diff -rq is het nuttigste commando uit dit artikel voor iedereen die servers beheert. Het beantwoordt "wat is er verschillend tussen deze twee kopieën van de site?" in een enkele regel, en het is het eerste om te draaien als een uitrol misgegaan is, als je vermoedt dat een kernbestand aangepast is, of als je wilt weten wat een update werkelijk veranderd heeft.

Een optie verandert de betekenis. -N behandelt een ontbrekend bestand als een leeg bestand, dus "alleen in" wordt "verschilt":

$ diff -rqN v1 v2
Files v1/added.txt and v2/added.txt differ
Files v1/changed.txt and v2/changed.txt differ
Files v1/inc/deep.txt and v2/inc/deep.txt differ
Files v1/removed.txt and v2/removed.txt differ

Gebruik -N als je een patch maakt, want een patch moet bestanden kunnen aanmaken en verwijderen. Laat hem weg als je de uitvoer zelf leest, want "alleen in" is informatiever dan "verschilt".

Voordat je hier iets van vertrouwt: lees paragraaf 7.1. diff -rq vergelijkt de inhoud van bestanden en verder niets, en wat het weglaat doet er meer toe dan de meeste mensen verwachten.

5.2 Bestanden en mappen uitsluiten

Op een echte site verzuipt het vorige commando in ruis. Caches, logs en gegenereerde miniaturen verschillen voortdurend en zeggen je niets:

$ diff -rq site-a site-b
Files site-a/cache/x.tmp and site-b/cache/x.tmp differ
Files site-a/index.php and site-b/index.php differ
Files site-a/logs/error.log and site-b/logs/error.log differ

Alleen de middelste regel doet ertoe. -x (kort voor exclude) neemt een patroon in shell-stijl en mag herhaald worden:

$ diff -rq -x cache -x '*.log' site-a site-b
Files site-a/index.php and site-b/index.php differ

Zodra de lijst groeit, zet je hem in een bestand en geef je dat mee met -X. Dat bestand hoort in versiebeheer, naast het script dat de vergelijking draait:

$ cat skip.txt
cache
logs
tmp
*.log

$ diff -rq -X skip.txt site-a site-b
Files site-a/index.php and site-b/index.php differ

Een regel pakt iedereen een keer: het patroon wordt vergeleken met de bestandsnaam, niet met het pad. Een pad met een schuine streep erin komt stilzwijgend met niets overeen:

$ diff -rq -x 'logs/*' site-a site-b
Files site-a/cache/x.tmp and site-b/cache/x.tmp differ
Files site-a/index.php and site-b/index.php differ
Files site-a/logs/error.log and site-b/logs/error.log differ    <-- not excluded

Sluit logs uit, niet logs/* en niet site-a/logs. De kale naam is waar diff elke regel mee vergelijkt terwijl hij de boom afloopt, en een map op naam uitsluiten slaat alles erin over.

5.3 Negeren wat je niet interesseert

Standaard telt elke byte mee, ook witruimte:

$ diff ws1.txt ws2.txt
1,2c1,2
< hello world
< second line
---
> hello  world
> second line   

De ene regel kreeg er een spatie in het midden bij, de andere spaties aan het eind, en allebei worden ze gemeld. Vier vlaggen zetten dat uit, van mildst naar breedst:

Er is ook -I, dat een reguliere expressie neemt en elke wijziging negeert op een regel die eraan voldoet. Zo vergelijk je twee gegenereerde rapporten zonder dat het tijdstempel bovenaan elk bestand anders laat lijken:

$ diff r1.txt r2.txt
1c1
< Generated: 2026-08-23
---
> Generated: 2026-08-24
$ echo $?
1

$ diff -I '^Generated:' r1.txt r2.txt
$ echo $?
0

Gebruik deze om te onderzoeken, niet om te beslissen. Een witruimtewijziging is onzichtbaar voor -w en zeer zichtbaar voor Python, YAML, en alles wat een here-document leest.

5.4 De valkuil van regeleindes

Af en toe toont een bestand dat "niemand aangeraakt heeft" elke regel als gewijzigd. Dit zijn vrijwel altijd de regeleindes, en het is het meest voorkomende loze alarm in webwerk, want een bestand dat op Windows bewerkt en via FTP geüpload is komt terug met een carriage return op elke regel.

$ diff crlf.txt lf.txt | cat -A
1,2c1,2$
< line one^M$
< line two^M$
---$
> line one$
> line two$

De ^M aan het eind van elke regel is de carriage return, zichtbaar gemaakt door cat -A. Zonder die truc zien beide kanten er identiek uit en lijkt de diff onzinnig. Twee commando's bevestigen het en een vlag negeert het:

$ file crlf.txt lf.txt
crlf.txt: ASCII text, with CRLF line terminators
lf.txt:   ASCII text

$ diff --strip-trailing-cr crlf.txt lf.txt ; echo $?
0

Het bestand echt repareren is beter dan het verschil voor altijd negeren. dos2unix doet dat, en sed -i 's/\r$//' bestand ook op een machine die dat programma niet heeft.

5.5 Als het geen tekst is

diff geeft het op bij binaire bestanden, en zegt dat ook:

$ diff bin1.dat bin2.dat
Binary files bin1.dat and bin2.dat differ

Dat is meestal alles wat je nodig hebt, en de afsluitcode werkt gewoon. Wil je details, dan is cmp het juiste gereedschap: dat vergelijkt byte voor byte en vertelt je waar het eerste verschil zit.

$ cmp bin1.dat bin2.dat
bin1.dat bin2.dat differ: byte 25, line 1

$ cmp -l bin1.dat bin2.dat | head -3
 25  60 300
 26 155  72
 41  50  30

cmp -l somt elke afwijkende byte op met zijn positie en de twee waarden in octaal. Voor een kale ja-of-nee op grote bestanden zijn cmp -s (stil) en diff -q even snel, want beide stoppen bij het eerste verschil; op twee identieke bestanden van 200 MB kostten ze hier 0,059s en 0,062s. Kies cmp als je wilt weten waar het verschil zit, en diff als je wilt weten wat het zegt.

Als je echt naar de bytes moet kijken, maak er dan eerst tekst van en vergelijk die. xxd maakt een hexdump met een regel per zestien bytes, en dat is precies de vorm die een regelgebaseerd gereedschap wil:

$ diff -u <(xxd h1.bin) <(xxd h2.bin)
@@ -1,4 +1,4 @@
 00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
-00000010: 0300 3e00 0100 0000 306d 0000 0000 0000  ..>.....0m......
-00000020: 4000 0000 0000 0000 2824 0200 0000 0000  @.......($......
+00000010: 0300 3e00 0100 0000 c03a 0000 0000 0000  ..>......:......
+00000020: 4000 0000 0000 0000 1892 0000 0000 0000  @...............

Dit maakt binaire formaten niet leesbaar, maar het maakt van "deze twee bestanden verschillen ergens" iets als "deze twee bestanden verschillen op positie 0x10 en 0x20", en dat is vaak genoeg om een versienummer, een tijdstempel of een headerveld te herkennen.

5.6 Dingen vergelijken die geen bestanden zijn

Bash laat je de uitvoer van een commando aanbieden aan alles dat een bestandsnaam verwacht, met <(...). Dat haalt de tijdelijke bestanden weg uit een hele categorie controles:

$ diff <(printf 'apache2\nmysql\nphp\n') <(printf 'apache2\nnginx\nphp\n')
2c2
< mysql
---
> nginx

Hetzelfde idee beantwoordt echte vragen over twee servers:

$ diff <(ssh web1 'dpkg -l | sort') <(ssh web2 'dpkg -l | sort')
$ diff <(ssh web1 'php -m | sort') <(ssh web2 'php -m | sort')
$ diff <(cd /var/www/live && find . | sort) <(cd /var/www/staging && find . | sort)

Sorteer beide kanten. diff vergelijkt op volgorde, dus twee identieke pakketlijsten in een andere volgorde leveren pagina's ruis op. Die ene gewoonte maakt deze techniek bruikbaar.

Er is een ruw randje. Omdat de "bestanden" anonieme pipes zijn, noemt de header ze naar bestandsdescriptors, en dat zegt je niets:

$ diff -u <(echo a) <(echo b) | head -2
--- /dev/fd/63	2026-08-23 18:33:16.048005790 +0200
+++ /dev/fd/62	2026-08-23 18:33:16.048005790 +0200

--label vervangt ze, een keer per kant, op volgorde:

$ diff -u --label production --label staging <(echo a) <(echo b) | head -2
--- production
+++ staging

Gebruik het zodra de uitvoer door iemand anders gelezen wordt of in een ticket geplakt. Een diff waarvan de twee kanten production en staging heten heeft geen uitleg nodig; een waarvan de kanten /dev/fd/63 en /dev/fd/62 heten heeft een alinea nodig.

5.7 Normaliseer voordat je vergelijkt

De vorige paragraaf eindigde op een gewoonte die het waard is om als regel op te schrijven: de beste vergelijking is meestal geen vergelijking van de ruwe invoer. Twee kanten kunnen dezelfde informatie in een andere volgorde, een andere opmaak of een andere codering bevatten, en een regelgebaseerd gereedschap meldt dat allemaal als wijziging.

Het patroon is altijd hetzelfde:

raw input  -->  normalise  -->  compare

Sorteer, en zet de taalinstelling vast. Beide kanten sorteren is de voor de hand liggende helft. De helft die vrijwel niemand noemt is dat de sorteervolgorde zelf van de taalinstelling afhangt, dus dezelfde gegevens gesorteerd op twee machines met verschillende taalinstellingen komen niet overeen:

$ cat loc.txt
apple
Banana
cherry

$ LC_ALL=en_US.UTF-8 sort loc.txt
apple Banana cherry

$ LC_ALL=C sort loc.txt
Banana apple cherry           <-- capitals first, by byte value

Vergelijk die twee volgordes met elkaar en je krijgt verschillen op elke regel, uit identieke invoer. Als de twee kanten van twee verschillende servers komen, is dat precies wat er gebeurt. Zet de taalinstelling aan beide kanten vast en het probleem verdwijnt:

$ diff <(LC_ALL=C sort list1.txt) <(LC_ALL=C sort list2.txt)
$ diff <(ssh web1 'LC_ALL=C dpkg-query -W | sort') \
       <(ssh web2 'LC_ALL=C dpkg-query -W | sort')

LC_ALL=C geeft een kale bytevolgorde die overal hetzelfde is. Het is niet de volgorde die een mens zou kiezen, en dat maakt niet uit, want niemand leest het: de twee kanten hoeven het alleen met elkaar eens te zijn.

Gebruik gereedschap dat het formaat kent, als dat bestaat. Opnieuw opgemaakte JSON is voor diff een volledige herschrijving, ook als er niets veranderd is. jq -S drukt het opnieuw af met gesorteerde sleutels, zodat alleen echte verschillen overblijven:

$ diff -u --label old --label new <(jq -S . old.json) <(jq -S . new.json)

Hetzelfde idee dekt de meeste klachten van het type "waarom is alles anders?": maak de XML netjes op, sorteer de databasedump, haal de tijdstempelregel weg met -I, maak de regeleindes gelijk. Doe het normaliseren een keer, in het commando, en de diff wordt leesbaar.

7. Iets wat de meeste gebruikers niet weten

7.1 diff -rq vergelijkt inhoud en verder niets

Paragraaf 5.1 noemde diff -rq het nuttigste commando uit dit artikel. Dat is het ook, en het zal je ook vertellen dat twee mappen overeenkomen terwijl ze wezenlijk verschillen, want het vergelijkt de inhoud van bestanden en verder niets.

Hier zijn twee mappen. Een bestand heeft in beide dezelfde inhoud, maar de permissies en het tijdstempel verschillen:

$ ls -l p1/f.txt p2/f.txt
-rw-r--r-- Jan  1  2020  p1/f.txt
-rwxrwxrwx Aug 23 17:16  p2/f.txt

$ diff -rq p1 p2
$ echo $?
0                                  <-- "identical"

Een bestand ging van 644 naar 777, schrijfbaar voor iedereen, en diff meldde helemaal niets. Op een website is dat het verschil tussen een dichtgezet bestand en een dat iedereen kan herschrijven, en een restore die zo gecontroleerd is komt met de verkeerde permissies door de test.

Bij symbolische links is het erger, want diff volgt ze. Hier is s1/ptr een symlink en s2/ptr een echt bestand met dezelfde inhoud:

$ ls -l s1/ptr s2/ptr
lrwxrwxrwx  s1/ptr -> real.txt
-rw-rw-r--  s2/ptr

$ diff -rq s1 s2
$ echo $?
0                                  <-- still "identical"

De structuur was vernield en de controle kwam erdoor. Voor elke site met de standaardindeling current -> releases/2026-08 bij het uitrollen is dat precies de storing die ertoe zou doen, en precies degene die dit commando verbergt.

Moderne GNU diff heeft er een vlag voor:

$ diff -rq --no-dereference s1 s2
File s1/ptr is a symbolic link while file s2/ptr is a regular file
$ echo $?
1

De eerlijke samenvatting van wat diff -rq controleert is dus kort:

Paragraaf 7.5 geeft het commando dat de rest afdekt.

7.2 Fuzz past je patch toe op code die verder is gegaan

Paragraaf 6.4 liet een patch luid falen zien. Dit is de storing die dat niet doet.

patch vindt een hunk door zijn contextregels te matchen. Als hij ze niet allemaal kan matchen, stopt hij niet: hij probeert het opnieuw terwijl hij de buitenste contextregels negeert. Het naslagwerk noemt de grens onomwonden:

$ man patch
       First patch looks for a place where all lines of the context match.
       If no such place is found, and it's a context diff, and the maximum
       fuzz factor is set to 1 or more, then another scan takes place
       ignoring the first and last line of context.  If that fails, and the
       maximum fuzz factor is set to 2 or more, the first two and last two
       lines of context are ignored, and another scan is made.
       (The default maximum fuzz factor is 2.)

Kijk wat dat toelaat. Hier is de functie waartegen de patch geschreven was door iemand anders hernoemd, dus de context komt niet meer overeen:

$ patch -p1 < ../fix.patch
patching file components/helper.php
Hunk #1 succeeded at 1 with fuzz 2.
$ echo $?
0

Afsluitcode 0. Een script ziet succes. Maar patch heeft zojuist een wijziging geschreven in een bestand waarvan de omringende code niet de code is waar de auteur van de patch naar keek, want hij gooide aan beide kanten twee regels context weg om een match te vinden.

Soms is dat precies goed en bespaart het je een middag. Soms zet het een correctie in een functie die niet langer de bedoelde functie is. Het punt is dat het je niet gevraagd werd.

patch die slaagt is niet hetzelfde als patch die gelijk heeft. Elke regel waarin fuzz voorkomt betekent dat het bestand opgeschoven was en dat patch gegokt heeft; lees wat hij gedaan heeft voordat je verdergaat.

Zet het gokken uit voor alles wat onbeheerd draait. -F0 zet de maximale fuzz op nul, zodat een hunk of precies past of faalt:

$ patch -p1 -F0 < ../fix.patch
patching file components/helper.php
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file components/helper.php.rej
$ echo $?
1

Dat is het gedrag dat je in een uitrolscript wilt: een duidelijke storing waar je op kunt handelen, in plaats van een stil succes dat je later moet ontdekken.

7.3 diff ziet geen verplaatst blok

diff vergelijkt niet regel 1 met regel 1 en regel 2 met regel 2. Als dat zo was, zou een regel bovenaan invoegen elke regel eronder als gewijzigd melden. In plaats daarvan zoekt hij de langste reeks regels die de twee bestanden gemeen hebben en behandelt hij de rest als toegevoegd of verwijderd, en daarom meldt het invoegen van een regel precies een toegevoegde regel.

Die uitlijning maakt diff bruikbaar, en ze heeft een blinde vlek: het begrip verplaatsing bestaat niet. Neem een bestand en verwissel de volgorde van twee functies, zonder er iets in te veranderen:

$ diff -u mv1.txt mv2.txt
@@ -1,6 +1,6 @@
 header
-function A
-body A
 function B
 body B
+function A
+body A
 footer

Er is niets toegevoegd en niets weggehaald, maar de diff toont twee verwijderingen en twee toevoegingen. Voor het gereedschap is er geen verschil tussen "dit blok is verplaatst" en "dit blok is hier weggehaald en daar is een identiek blok geschreven".

Dat doet ertoe bij review. Een patch die een groot bestand herordent ziet er enorm uit en leest alsof alles herschreven is, en de echt nieuwe regels liggen begraven tussen de verplaatste. Drie uitwegen, op volgorde van hoeveel je moet installeren:

• Meng verplaatsingen niet met bewerkingen. Ga je een bestand herordenen, doe dat dan in een wijziging die alleen herordent, zodat de volgende diff leesbaar is.
• Vraag om een andere uitlijning. -d (--minimal) vraagt diff om extra moeite te doen om een kleinere set wijzigingen te vinden. Het is trager, en op eenvoudige bestanden geeft het meestal hetzelfde antwoord, maar bij een slecht uitgelijnde diff is het een poging waard.
• Gebruik gereedschap dat verplaatsingen volgt bij het reviewen, zoals git diff --color-moved, dat verplaatste blokken in een andere kleur zet in plaats van te doen alsof ze nieuw zijn.

Het bredere punt is dat een diff een geldige beschrijving is van hoe je van A naar B komt, niet de enige en niet per se degene die een mens geschreven zou hebben. Twee gereedschappen kunnen voor hetzelfde paar bestanden verschillend ogende uitvoer geven en allebei gelijk hebben.

7.4 Een diff is een programma, geen rapport

Al het andere in dit artikel volgt uit een idee dat makkelijk te missen is: de uitvoer van diff is met opzet machineleesbaar, en de machine die hem leest is patch.

Daarom is het formaat zo pietluttig. De spatie vooraan een contextregel is geen versiering, het is de markering voor "ongewijzigd", en hem weghalen breekt de patch. De regeltellingen in de @@-header moeten overeenkomen met het aantal regels dat volgt. Een editor die spaties aan het eind weghaalt kan een patchbestand ongeldig maken. Een mailprogramma dat lange regels afbreekt ook, en daarom werden patches van oudsher als bijlage verstuurd en heeft elk project een pagina over hoe je ze niet verminkt.

Het verklaart ook de twee regels die mensen verrassen:

• Bewerk nooit een patchbestand om het te "repareren", tenzij je bereid bent de regeltellingen in elke hunk-header die je aanraakt mee te corrigeren.
• Laat nooit kleur in een patch komen. --color=always > fix.patch levert een bestand op dat er perfect uitziet en dat patch niet kan lezen, want elke regel begint nu met een escape-reeks in plaats van met een spatie, een plus of een min.

7.5 Een teruggezette backup goed controleren

Zet 7.1 naast de rest en je krijgt de controle die na een restore of een verhuizing werkelijk de moeite waard is. Hij bestaat uit twee helften, want geen enkel commando dekt allebei.

Eerst de inhoud:

$ diff -rq --no-dereference /var/www/live /mnt/restore/live

Daarna alles wat diff negeert, door de metagegevens in tekst om te zetten en die te vergelijken:

$ diff \
    <(cd /var/www/live   && find . -printf '%p %m %u:%g\n' | sort) \
    <(cd /mnt/restore/live && find . -printf '%p %m %u:%g\n' | sort)
3c3
< ./f.txt 644 www-data:www-data
---
> ./f.txt 777 www-data:www-data

De opmaakreeks van find -printf doet het werk: %p het pad, %m de permissiebits in octaal, %u:%g de eigenaar en de groep. Beide kanten sorteren maakt de vergelijking stabiel. Het resultaat is een regel per bestand waarvan de modus of het eigendom veranderde, en dat is precies wat de inhoudsvergelijking niet kan zien.

Ditzelfde paar commando's beantwoordt een tweede vraag die vaker opkomt dan iemand zou willen: is er iets op deze site gewijzigd dat niet gewijzigd had mogen worden? Download een schone kopie van dezelfde versie en vergelijk die met de draaiende site. Elk bestand dat verschilt is of je eigen aanpassing, of iets waar je heel goed naar moet kijken.

Trek het nog een stap breder en je hebt de nuttigste gewoonte uit dit artikel. Leg de toestand als tekst vast voordat je iets verandert, leg hem daarna opnieuw vast, en vergelijk de twee. Het kost twee commando's en het beantwoordt precies "wat heeft dat nu eigenlijk gedaan?":

$ before=$(mktemp) after=$(mktemp)
$ trap 'rm -f "$before" "$after"' EXIT

$ dpkg-query -W | LC_ALL=C sort > "$before"
$ sudo apt upgrade
$ dpkg-query -W | LC_ALL=C sort > "$after"

$ diff -u --label before --label after "$before" "$after"

De trap-regel maakt het veilig om in een script te zetten: de tijdelijke bestanden worden ook opgeruimd als het vroegtijdig stopt. Alles wat tekst afdrukt werkt als momentopname, en op Linux is dat vrijwel alles:

find /etc -type f | LC_ALL=C sort        which configuration files exist
systemctl list-unit-files --state=enabled   which services will start
ss -tulpn                               which ports are listening
php -m | LC_ALL=C sort                  which PHP extensions are loaded
crontab -l ; ls /etc/cron.d             what is scheduled

Draai een van die commando's voor een verhuizing en daarna nog eens, en de verschillen tussen de twee servers zijn geen kwestie van geheugen meer.

7.6 Weten waar diff ophoudt

Een deel van vakmanschap is weten wanneer een gereedschap het verkeerde is.

Die laatste rij wordt te weinig gebruikt. Heb je twee lijsten met namen, dan beantwoorden comm -13 en comm -23 de vraag "wat staat alleen aan deze kant?" directer dan een diff lezen.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen om te vermijden

• Ongesorteerde uitvoer vergelijken. diff <(ssh a 'dpkg -l') <(ssh b 'dpkg -l') zonder sort aan beide kanten levert een diff van de volgorde op, niet van de inhoud.
• De volgorde van de argumenten omdraaien. diff nieuw oud is een geldig commando dat een patch oplevert die jouw werk ongedaan maakt. Het eerste bestand is altijd het "van".
• -N vergeten bij een patch voor een hele boom. Zonder die vlag worden bestanden die maar aan een kant bestaan als "Only in" genoemd en niet meegenomen, dus de patch kan ze stilzwijgend niet aanmaken.
• Een patch vanuit de verkeerde map toepassen. Het -p-niveau en je werkmap zijn twee helften van dezelfde instelling. Krijg er een verkeerd en je krijgt "can't find file to patch", of erger: je patcht een bestand met dezelfde naam ergens anders.
• -w gebruiken om een verschil te laten verdwijnen. Witruimte is betekenisvol in Python, YAML, Makefiles en here-documents. -w is om te onderzoeken, niet om te concluderen.
• Een patchbestand met de hand bewerken. De regeltellingen in de @@-headers moeten kloppen met de regels die volgen, en niets waarschuwt je als dat niet zo is.
• Een diff van een gegenereerd bestand vertrouwen. Geminificeerde assets, gecompileerde templates en cachebestanden verschillen voortdurend om redenen die niemand hoeft te zien. Sluit ze uit, of vergelijk de bronnen waar ze uit komen.
• Een uitsluiting als pad schrijven. -x 'logs/*' en -x 'site/cache' komen allebei met niets overeen, stilzwijgend. Het patroon wordt getest tegen de kale naam van elke regel.
• Twee servers vergelijken zonder de taalinstelling vast te zetten. Verschilt LANG ertussen, dan levert sort aan elke kant een andere volgorde op en is de diff louter ruis. LC_ALL=C sort aan beide kanten.
• .orig-bestanden in een webroot laten staan. helper.php.orig wordt niet door PHP uitgevoerd, wat betekent dat de webserver hem als platte tekst kan uitleveren, inclusief alles wat erin staat. Ruim ze op.