Linux commando: sort

Bijna iedereen leert sort in zijn eerste week Linux en leert het daarna nooit meer. Het zet regels op volgorde, en dat lijkt het hele verhaal. Dat is het niet. sort bepaalt de volgorde met regels die uit je omgeving komen en niet uit je commandoregel, dus hetzelfde commando op hetzelfde bestand kan op twee machines twee verschillende antwoorden geven. Het sorteert getallen verkeerd tenzij je vertelt dat het getallen zijn. De -u kan stilletjes een regel weggooien die je wilde houden, en -k2 betekent bijna nooit wat mensen denken dat het betekent. Het is bovendien een van de weinige commando's in dagelijks gebruik die het geheugen van een server kunnen opmaken. Dit artikel gaat over wat sort echt vergelijkt, en hoe je het laat vergelijken wat je bedoelde.

2. Waar komt de naam vandaan?

Hier zit geen raadsel, en dat is op zichzelf al opvallend. De buren uit dezelfde tijd zijn tot op het bot afgekort: ls, cp, mv, rm, du, df, wc. sort hield al zijn vier letters omdat er geen voor de hand liggende manier was om het korter te maken en toch begrepen te worden. srt had een toetsaanslag bespaard en veel duidelijkheid gekost.

De woordenschat is waar de echte verwarring zit, want sort gebruikt een paar gewone woorden op een heel specifieke manier. Elk van deze termen veroorzaakt ergens in dit artikel een misverstand:

line             what sort moves around; the trailing newline is not compared
key              the part of a line sort actually compares (default: all of it)
field            a numbered piece of a line, counting from 1
separator        what divides fields; by default a run of blanks, -t changes it
collation        the rules that decide which string comes first
locale           where those rules come from: LC_COLLATE, or LC_ALL, or LANG
stable           lines that compare equal keep their input order  (-s)
last resort      when every key ties, sort compares the whole line anyway
merge            combining already-sorted inputs without sorting again  (-m)
external sort    sorting more data than fits in memory, using temporary files

Twee daarvan verdienen nu meteen een waarschuwing. Een sleutel is niet hetzelfde als een veld: -k2 benoemt een sleutel die begint bij veld 2 en doorloopt tot het einde van de regel, en dat is paragraaf 5.2 en de meest gemaakte fout met dit commando. En laatste redmiddel betekent dat sort stilletjes dingen vergelijkt die je nooit hebt gevraagd te vergelijken, en dat is paragraaf 6.1 en de reden dat de uitvoer voorspelbaar is waar je een gelijkspel verwachtte.

De handleiding is eerlijk over de locale-valkuil uit paragraaf 1.3, en schreeuwt erover, wat de GNU-handleidingen bijna nooit doen:

$ man sort | grep -A3 WARNING
       ***  WARNING  ***  The locale specified by the environment affects sort
       order.  Set LC_ALL=C to get the traditional sort order that uses native
       byte values.

4. Eenvoudige toepassingen

4.1 Alfabetisch, en achterstevoren

-r (kort voor reverse) sorteert niet achterstevoren. Het draait het resultaat van elke afzonderlijke vergelijking om, wat op hetzelfde neerkomt bij een gewone sortering maar uitmaakt zodra je meerdere sleutels hebt (paragraaf 5.4):

$ sort -r fruit.txt
Banana
banana
Apple
apple

Meerdere bestanden worden behandeld als een lang bestand: eerst aan elkaar geplakt en dan gesorteerd. Dat is iets anders dan ze allemaal apart sorteren:

$ sort file1.txt file2.txt file3.txt      # one merged, sorted stream

4.2 Getallen: -n, -g en -h

Er zijn drie numerieke sorteringen en ze zijn niet uitwisselbaar. De verkeerde kiezen levert een geloofwaardig ogend fout antwoord op, en dat is de ergste soort.

Het verschil tussen -n en -g is in een voorbeeld te zien:

$ printf '1e3\n5\n0.5\n2\n-1\ninf\nnan\n' > gen.txt

$ sort -n gen.txt
-1
inf                       # -n cannot read these, so both count as 0
nan
0.5
1e3                       # and this counts as 1, not 1000
2
5

$ sort -g gen.txt
nan
-1
0.5
2
5
1e3                       # 1000, correctly at the top
inf

De omgekeerde valkuil is net zo echt. -n respecteert het duizendtalscheidingsteken van je locale en -g niet:

$ printf '1,200\n999\n1,100\n' | sort -n       # en_US.UTF-8
999
1,100
1,200

$ printf '1,200\n999\n1,100\n' | sort -g
1,100                     # both read as "1", then compared as text
1,200
999

-h bestaat omdat -n er een potje van maakt bij mensleesbare groottes. Het leest het achtervoegsel in plaats van ervoor te stoppen:

$ printf '1.4G\n900M\n2K\n1023\n1.1T\n' > sizes.txt

$ sort -h sizes.txt
1023
2K
900M
1.4G
1.1T

$ sort -n sizes.txt
1.1T                      # 1.1, 1.4, 2, 900, 1023: the suffix is ignored
1.4G
2K
900M
1023

De koppelregel is het onthouden waard, want die twee door elkaar halen is een veelvoorkomende pipeline-fout: -h hoort bij uitvoer met achtervoegsels, -n hoort bij uitvoer zonder. du -h | sort -h klopt en du -k | sort -n klopt; du -h | sort -n is het verkeerde antwoord, keurig aangekleed.

4.3 Versies: -V

-V (kort voor Version) sorteert zoals een mens een versienummer leest, en dat is noch tekstvolgorde noch numerieke volgorde:

$ printf 'v1.10\nv1.9\nv1.2\nv1.21\n' > vers.txt

$ sort vers.txt
v1.10
v1.2
v1.21
v1.9

$ sort -V vers.txt
v1.2
v1.9
v1.10
v1.21

Het is niet alleen voor versienummers. Het is het juiste gereedschap voor alles waar cijfers in tekst zitten: log.2 voor log.10, eth1 voor eth10, photo-9.jpg voor photo-10.jpg. Het sorteert toevallig ook IPv4-adressen correct, wat mensen verbaast:

$ printf '10.0.0.9\n10.0.0.100\n10.0.2.1\n9.1.1.1\n10.0.0.10\n' | sort -V
9.1.1.1
10.0.0.9
10.0.0.10
10.0.0.100
10.0.2.1

4.4 Duplicaten verwijderen: -u

-u (kort voor unique) houdt alleen de eerste regel van elke reeks gelijke regels over. Het vervangt het oudere sort | uniq en scheelt een proces:

$ printf 'a\nb\na\nb\na\n' | sort -u
a
b

Twee dingen eraan gaan je later bijten, en allebei hebben ze een eigen paragraaf. -u bepaalt "gelijk" met de vergelijking die op dat moment geldt, niet door bytes te vergelijken, dus sort -uf en sort -un gooien veel meer weg dan je verwacht (paragraaf 7.3). En sort -u vernietigt precies de informatie die uniq -c je had gegeven, en daarom gebruikt de frequentieteller in paragraaf 5.6 uniq in plaats van -u.

4.5 Sorteren is niet hetzelfde als tellen

De verwanten van sort hebben allemaal gesorteerde invoer nodig, en dat is precies waarom sort vooraan in zoveel pipelines opduikt. uniq vergelijkt een regel alleen met de regel er direct voor:

$ printf 'a\nb\na\nb\na\n' | uniq
a
b
a
b
a                         # nothing removed: no two neighbours were equal

$ printf 'a\nb\na\nb\na\n' | sort | uniq
a
b

Hetzelfde geldt voor comm en join, en dat is paragraaf 7.1.

4.6 Het resultaat wegschrijven: -o, en de valkuil ernaast

De voor de hand liggende manier om een bestand ter plekke te sorteren is de manier die het vernietigt:

$ cat danger.txt
c
a
b

$ sort danger.txt > danger.txt
$ wc -c < danger.txt
0                         # the file is gone

Dat is niet de schuld van sort. De shell maakt danger.txt aan en kapt het af voordat sort ook maar begint, dus sort opent een leeg bestand, leest niets en schrijft niets. Elk commando in de shell gedraagt zich zo; sort is toevallig het commando waarmee mensen het proberen.

-o (kort voor output) is de oplossing, en die kent dit geval al sinds Version 4 Unix. sort leest de invoer volledig voordat het de uitvoer opent, dus hetzelfde bestand noemen is uitdrukkelijk veilig:

$ printf 'c\na\nb\n' > safe.txt
$ sort -o safe.txt safe.txt
$ cat safe.txt
a
b
c

Het is zelfs veilig als het uitvoerbestand een van meerdere invoerbestanden is:

$ printf 'c\na\n' > o1.txt ; printf 'd\nb\n' > o2.txt
$ sort -o o1.txt o1.txt o2.txt
$ cat o1.txt
a
b
c
d

6. Gevorderde toepassingen

6.1 Gelijkspel, stabiliteit en de vergelijking als laatste redmiddel

Wat doet sort als twee regels op elke sleutel die je hebt opgegeven gelijk uitkomen? De meeste mensen nemen aan dat het ze met rust laat. Dat doet het niet. GNU sort valt terug op het vergelijken van de hele regel, alsof je helemaal geen opties had opgegeven behalve -r. De handleiding noemt dit de last-resort comparison.

$ cat stab.txt
2 zebra
1 apple
2 apple
1 zebra

$ sort -k1,1n stab.txt
1 apple
1 zebra
2 apple
2 zebra                   # the second column got sorted too, uninvited

Veld 2 werd nergens op die commandoregel genoemd. sort vergeleek het toch, omdat beide regels op veld 1 gelijk uitkwamen. -s (kort voor stable) zet die terugval uit, en gelijke regels houden dan hun oorspronkelijke volgorde:

$ sort -s -k1,1n stab.txt
1 apple
1 zebra
2 zebra
2 apple                   # input order preserved within each group

Dit is belangrijker dan het lijkt. De vergelijking als laatste redmiddel is wat GNU sort voorspelbaar maakt: draai het twee keer op dezelfde invoer en je krijgt dezelfde uitvoer, ongeacht hoe de samenvoeging de regels toevallig door elkaar heeft geweven. Zet het uit met -s en de volgorde binnen een groep wordt de invoervolgorde, en dat is wat je wilt als je gegevens sorteert die al een betekenisvolle volgorde hebben, zoals een logbestand dat je op ernst hebt gesorteerd maar binnen elke ernst op tijd wilt houden.

Het lastige is dat -u die terugval ook uitzet, en stilzwijgend. Die combinatie is paragraaf 7.3, en er kunnen gegevens door verloren gaan.

6.2 Controleren in plaats van sorteren: -c en -C

-c (kort voor check) sorteert niet. Het meldt of de invoer al op volgorde staat en vertelt je de eerste regel die dat niet is:

$ printf 'a\nc\nb\n' > unsorted.txt
$ sort -c unsorted.txt
sort: unsorted.txt:3: disorder: b
$ echo $?
1

$ printf 'a\nb\nc\n' | sort -c
$ echo $?
0

-C is dezelfde controle zonder melding, voor scripts die alleen de exitcode willen. De drie exitcodes zijn het kennen waard, want het zijn niet de gebruikelijke twee:

$ sort /nonexistent
sort: cannot read: /nonexistent: No such file or directory
$ echo $?
2

-u aan een controle toevoegen maakt er een controle op strikte volgorde van, wat betekent dat duplicaten nu als wanorde tellen. Dat is een duplicaatdetector van een enkele regel:

$ printf 'a\na\nb\n' | sort -c
$ echo $?
0                         # sorted: duplicates are allowed

$ printf 'a\na\nb\n' | sort -cu
sort: -:2: disorder: a
$ echo $?
1                         # not strictly sorted: there is a duplicate

In een script is sort -C veel goedkoper dan een groot bestand sorteren waarvan je vermoedt dat het al gesorteerd is, want het buffert niets: het streamt, vergelijkt elke regel met de vorige, en stopt bij het eerste probleem.

6.3 Al gesorteerde bestanden samenvoegen: -m

-m (kort voor merge) combineert bestanden die al gesorteerd zijn, zonder ze opnieuw te sorteren. Het streamt, dus het heeft vrijwel geen geheugen nodig, hoe groot de bestanden ook zijn:

$ printf '1\n3\n5\n' > m1.txt ; printf '2\n4\n6\n' > m2.txt
$ sort -m m1.txt m2.txt
1
2
3
4
5
6

Het vertrouwt je volledig. Geef het ongesorteerde invoer en het levert ongesorteerde uitvoer zonder enige waarschuwing:

$ printf '5\n1\n' > m3.txt
$ sort -m m1.txt m3.txt
1
3
5
5
1                         # garbage, silently

Er is een tweede eis die makkelijker te missen is, want elke invoer kan perfect gesorteerd zijn en de samenvoeging levert alsnog onzin op. De invoeren moeten volgens dezelfde regels gesorteerd zijn. Voeg een bestand dat in de C-locale is gesorteerd samen met een bestand uit een UTF-8-locale en het resultaat staat in geen van beide volgordes:

$ printf 'a-b\nab\nAb\n' | LC_ALL=C sort > p1.txt      # byte order
$ printf 'a-c\nac\nAc\n' | sort > p2.txt              # locale order

$ LC_ALL=C sort -m p1.txt p2.txt
Ab
a-b
a-c
ab
ac
Ac

$ LC_ALL=C sort -m p1.txt p2.txt | LC_ALL=C sort -c
sort: -:6: disorder: Ac                # the merge output is not sorted at all

Hetzelfde geldt voor de sleutel. sort -m -k2,2 over bestanden die op veld 1 zijn gesorteerd, weeft ze door elkaar op veld 2 en levert rommel op, zonder een woord van protest. Een samenvoeging is niet beter dan de belofte die je doet over de invoer, en sort neemt die belofte volledig op vertrouwen aan.

-m is dus het juiste gereedschap voor geroteerde logbestanden, dagelijkse exports en al het andere dat in voorgesorteerde brokken binnenkomt, zolang elke brok door hetzelfde commando in dezelfde omgeving is gemaakt. Het is het verkeerde gereedschap voor alles wat je niet hebt gecontroleerd, dus combineer het met -C en zet de locale aan beide kanten uitdrukkelijk vast:

$ export LC_ALL=C
$ for f in chunk-*.txt; do sort -C "$f" || { echo "$f is not sorted"; exit 1; }; done
$ sort -m chunk-*.txt > merged.txt

6.4 Tekenposities binnen een veld

Het .C-deel van een sleutel selecteert tekens binnen een veld, waarmee je op een deel van een veld kunt sorteren zonder de regel eerst uit elkaar te knippen. Met tijdstempels van vaste breedte:

$ cat logs.txt
2026-03-01 12:00:00 ERROR disk
2026-01-15 08:30:00 WARN  net
2026-01-15 22:00:00 INFO  boot
2025-12-31 23:59:59 ERROR eol

$ sort -k2.1,2.2 logs.txt         # by the hour only
2026-01-15 08:30:00 WARN  net
2026-03-01 12:00:00 ERROR disk
2025-12-31 23:59:59 ERROR eol
2026-01-15 22:00:00 INFO  boot

$ sort -k1.6,1.7 logs.txt         # by the month inside the date
2026-01-15 08:30:00 WARN  net
2026-01-15 22:00:00 INFO  boot
2026-03-01 12:00:00 ERROR disk
2025-12-31 23:59:59 ERROR eol

-k1.6,1.7 hardop lezen helpt: "veld 1, tekens 6 tot en met 7". Dat is de maand in een ISO-datum.

Dit werkt alleen op gegevens die echt een vaste breedte hebben. Als het veld een teken kan opschuiven, bouw dan eerst een fatsoenlijke kolom met awk. Dat brengt het algemene principe naar boven: sorteren op een ISO 8601-datum heeft helemaal geen opties nodig, want YYYY-MM-DD is zo ontworpen dat tekstvolgorde en datumvolgorde hetzelfde zijn. Als jij de opmaak bepaalt, is dat de opmaak die je kiest.

6.5 Maanden, spaties, hoofdletters en leestekens

Er bestaan vier kleinere sorteeropties, en drie ervan zijn nuttiger dan ze lijken.

-M (kort voor Month) begrijpt maandafkortingen, waarbij alles wat het niet herkent vooraan sorteert:

$ printf 'Mar\nJan\nFeb\nDec\nfoo\nJul\n' | sort -M
foo
Jan
Feb
Mar
Jul
Dec

Het maakt geen onderscheid tussen hoofdletters en kleine letters, en het accepteert volledige maandnamen naast namen van drie letters. De namen die het accepteert komen uit je locale, waardoor het nutteloos is op een server waarvan je de locale niet beheert en een valkuil op een server waarvan de locale niet Engels is.

-b (kort voor ignore leading blanks) haalt spaties aan het begin uit de sleutel voordat er wordt vergeleken. In bytevolgorde sorteert een spatie voor elke letter, dus zonder deze optie drijven ingesprongen regels naar boven:

$ printf '  zulu\nbravo\n' > blank.txt

$ LC_ALL=C sort blank.txt
  zulu                    # the two spaces win
bravo

$ LC_ALL=C sort -b blank.txt
bravo
  zulu

-f (kort voor case fold) maakt de vergelijking hoofdletterongevoelig. In een UTF-8-locale ligt dat toch al dicht bij het standaardgedrag; in de C-locale verandert het alles:

$ printf 'Zebra\napple\nBanana\n' > f.txt

$ LC_ALL=C sort f.txt
Banana
Zebra
apple                     # all capitals first

$ LC_ALL=C sort -f f.txt
apple
Banana
Zebra

-d (kort voor dictionary order) kijkt alleen naar letters, cijfers en spaties, en negeert leestekens. -i (kort voor ignore non-printing) laat stuurtekens zoals tabs en escape-reeksen buiten de vergelijking, wat af en toe nuttig is bij gekleurde commando-uitvoer die naar een bestand is weggeschreven.

LC_ALL=C sort -df is een redelijke benadering van "sorteer dit zoals een telefoonboek het zou doen", en anders dan een UTF-8-locale gedraagt het zich na een glibc-upgrade nog steeds hetzelfde.

6.6 Bestandsnamen: -z en --files0-from

Bestandsnamen mogen regeleindes bevatten. Dat is toegestaan op Linux, en het betekent dat elke pipeline die op regels is gebouwd door een bestandsnaam kapot kan gaan, met opzet of per ongeluk. -z (kort voor zero-terminated) zet zowel invoer als uitvoer om naar NUL-bytes, en die kunnen niet in een bestandsnaam voorkomen:

$ find /var/www -type f -print0 | sort -z | xargs -0 ls -l

Elk gereedschap in die keten gebruikt de NUL-afspraak: find -print0, sort -z, xargs -0. Ze mengen met een regelgebaseerd gereedschap doet het nut teniet. grep -z, sed -z en du --files0-from=- zijn de andere leden van de familie.

sort heeft ook --files0-from=F, dat de lijst met invoerbestanden uit een met NUL gescheiden lijst leest in plaats van van de commandoregel. Daarmee vermijd je de grens "argument list too long" als je heel veel bestanden hebt:

$ find /var/log -name '*.csv' -print0 > list0
$ sort --files0-from=list0 -t, -k2,2n > combined.csv

6.7 Schudden: -R

-R (kort voor Random) wordt in de handleiding beschreven als "shuffle, but group identical keys", en die tweede helft is het deel dat ertoe doet. Het hasht de sleutel en sorteert op de hash, dus identieke regels komen alsnog naast elkaar te staan:

$ printf 'a\na\nb\nb\nc\nc\n' | sort -R --random-source=seed
b
b
c
c
a
a                         # groups intact, group order random

$ printf 'a\na\nb\nb\nc\nc\n' | shuf --random-source=seed
b
c
b
a
c
a                         # genuinely shuffled

De precieze volgorde hangt af van het seedbestand, dus je eigen resultaat ziet er anders uit. Wat niet verandert is de vorm: sort -R houdt de paren bij elkaar en shuf niet.

Als je echt wilt schudden, gebruik dan shuf. Als je de volgorde van groepen willekeurig wilt maken terwijl elke groep bij elkaar blijft, is sort -R het enige dat dat doet. Allebei accepteren ze --random-source, wat het resultaat herhaalbaar maakt: hetzelfde seedbestand geeft elke keer dezelfde volgorde, en dat is wat je in een test wilt.

6.8 Als het niet past: de external merge sort

Paragraaf 1.2 zei dat sort de hele invoer moet vasthouden voordat het iets kan uitvoeren. Dat roept een voor de hand liggende vraag op: wat gebeurt er als die hele invoer niet in het geheugen past? Veel mensen nemen aan dat het faalt, of gaat swappen. Het doet geen van beide. Het wisselt van strategie, en die strategie is het begrijpen waard, want hij verklaart elke afstemoptie in de volgende paragraaf.

De techniek heet een external merge sort, en werkt in twee fasen:

PHASE 1  make runs                PHASE 2  merge runs
read as much as the buffer holds  open 16 runs at once
sort it in memory                 read the smallest line from each
write it out as a sorted "run"    write it to the output
repeat until the input is gone    repeat until every run is empty
                                  more than 16 runs left? merge again

Elke run is gesorteerd, dus voor het samenvoegen is er per run maar een regel tegelijk in het geheugen nodig, hoe groot de runs ook zijn. Dat is de hele truc: sorteren heeft alles tegelijk nodig, samenvoegen niet.

Je kunt het zien gebeuren. Geef sort een kleine buffer, laat -T naar een map wijzen die je kunt zien, en tel de bestanden erin terwijl de sortering loopt:

$ sort -S 10M -T ./tmpdir big.txt -o /dev/null &
$ while kill -0 $! 2>/dev/null; do ls tmpdir | wc -l; done | uniq

0 1 2 3 4 5 6 7 8 ... 66 67 68 69      <- phase 1: one run at a time
69 63 57 54 53 46 39 35 29 24 23       <- phase 2: runs consumed and merged
16 10 8 3 2 1 0

De klim naar 69 is fase 1: de invoer van 62 MB gedeeld door een buffer van 10 MB. De daling is fase 2. Het is geen nette trap, want elke samenvoeging verwijdert zijn zestien invoeren een voor een terwijl het ze leegt en zijn eigen uitvoerbestand er al staat, dus het aantal wiebelt omlaag in plaats van in blokken te zakken.

Zestien is geen gok: --batch-size staat standaard op 16, en de coreutils-handleiding zegt dat ook. Met 69 runs betekent dat dat sort het niet in een enkele ronde kan. Het voegt groepen van 16 samen tot nieuwe tijdelijke bestanden en voegt die daarna weer samen, dus de gegevens worden onderweg naar buiten twee keer gelezen en herschreven. De volgende alinea's zetten een getal op wat dat kost.

De grootte van de buffer bepaalt hoeveel runs er zijn, en dat is het enige wat -S echt regelt:

Lees de laatste drie rijen goed, want daar staat het nuttigste praktische feit uit deze paragraaf. -S 50M was net zo snel als de standaardinstelling en gebruikte een dertiende van het geheugen. Zodra het aantal runs onder de batchgrootte zakt, is een enkele samenvoegronde genoeg, en levert meer geheugen kopen daarna niets meer op. Merk ook op dat -S 2G geen 2 GB gebruikte: -S is een plafond, geen reservering.

De reden zie je het makkelijkst als je stopt met seconden tellen en verplaatste bytes gaat tellen. Voor een external sort is dat de eenheid die telt, want elke samenvoegronde leest en herschrijft de volledige gegevensset. Gemeten op hetzelfde bestand van 62 MB, als totaal aantal gelezen plus geschreven bytes door het proces:

in memory, no runs        61 MB read  +  61 MB written  =   123 MB   ( 2x )
-S 50M,  14 runs, 1 pass 123 MB read  + 123 MB written  =   247 MB   ( 4x )
-S 10M,  69 runs, 2 pass 182 MB read  + 182 MB written  =   365 MB   ( 6x )

Elke samenvoegronde kost een extra volledige leesbeurt en een extra volledige schrijfbeurt. Dat is het hele kostenmodel, en het verandert --batch-size van een mysterie in rekenwerk. Als je meer rondes afdwingt op dezelfde 136 runs:

$ sort -S 5M --batch-size=2   ...   1091 MB moved
$ sort -S 5M --batch-size=4   ...    611 MB moved
$ sort -S 5M --batch-size=16  ...    365 MB moved    (the default)
$ sort -S 5M --batch-size=200 ...    247 MB moved    (all 136 runs at once)

Voor een sortering die in het geheugen past, denk je in seconden. Voor een sortering die dat niet doet, denk je in verplaatste bytes. Elke extra samenvoegronde herschrijft je volledige gegevensset, en de buffergrootte is alleen interessant omdat die bepaalt hoeveel rondes er zijn.

Dit verklaart ook de fout No space left on device die nachtelijke taken velt. De runs bestaan allemaal tegelijk voordat het samenvoegen begint, dus een sortering heeft tijdelijke ruimte nodig van ongeveer de grootte van de invoer, in /tmp, bovenop de ruimte die de uitvoer ergens anders inneemt.

6.9 Een grote sortering afstemmen

Vijf opties regelen de machinerie uit de vorige paragraaf. Alleen de eerste twee zijn het waard om vaak aan te komen.

Alle getallen hier komen van hetzelfde bestand van 5.000.000 regels en 62 MB op een machine. Tot het uiterste doorgetrokken levert een piepkleine buffer veel runs en een trage sortering op:

$ sort -S 1M -T ./tmpdir big.txt -o /dev/null       1.66 s, 717 temporary files
$ sort            big.txt -o /dev/null              0.82 s, no temporary files

Voor -T volgen daar twee dingen uit. Ten eerste faalt een grote sortering met No space left on device als /tmp klein is, ook al heeft de schijf met je gegevens ruimte zat, want de tijdelijke bestanden belanden ergens anders. Het piekgebruik aan tijdelijke ruimte was in de run hierboven ongeveer 87 MB voor een invoer van 62 MB. Ten tweede is -T naar een tmpfs laten wijzen niet altijd winst: tmpfs zit in RAM, dus je hebt het geheugenprobleem verplaatst en niet opgelost.

Voor -S is het praktische advies het tegenovergestelde van wat mensen verwachten. Grijp niet naar een groot getal. Grijp naar een getal dat het aantal runs onder de batchgrootte brengt en stop daar: op dit bestand evenaarde -S 50M de snelheid van de standaardinstelling met een dertiende van het geheugen. Een plafond beschermt ook de rest van de machine, want de standaardinstelling pakt wat het nodig heeft.

Compressie is de optie waar mensen het eerst naar grijpen en die ze het minst nodig hebben:

$ sort -S 1M -T ./tmpdir big.txt -o /dev/null                        1.61 s
$ sort -S 1M -T ./tmpdir --compress-program=gzip big.txt -o /dev/null 7.37 s

Op een NVMe-SSD maakte het comprimeren van tijdelijke bestanden de sortering vierenhalf keer trager. Het loont alleen als het tijdelijke bestandssysteem echt te klein of echt traag is, zoals een netwerkschijf. Meet voordat je het toevoegt.

8. Best practices

• Zet export LC_ALL=C bovenaan elk script dat sorteert. Het maakt de volgorde identiek op elke machine, onder cron, in een container en na een OS-upgrade, en het is ruwweg twee keer zo snel. Laat de locale alleen met rust voor uitvoer die een mens gaat lezen.
• Schrijf altijd het einde van de sleutel erbij. -k2,2, niet -k2. De komma is het verschil tussen "veld 2" en "veld 2 tot het einde van de regel", en de verkeerde vorm is meestal per ongeluk goed totdat hij dat niet is.
• Zet de sorteerletter op de sleutel. -k3,3n, niet -n -k3,3. Een globale -n geldt voor elke sleutel en verandert je tekstsleutel in nul.
• Grijp naar --debug zodra er iets vreemds uitkomt. Het onderstreept precies de bytes die worden vergeleken en noemt de locale. Het beantwoordt in een seconde wat raden in tien minuten beantwoordt.
• Leer de frequentieteller uit je hoofd: sort | uniq -c | sort -rn | head. Hij beantwoordt de meeste logvragen.
• Gebruik -o bestand, nooit > bestand, als de uitvoer terug naar de invoer gaat. De shell kapt het bestand af voordat sort het opent.
• Kies de numerieke sortering die bij de gegevens hoort. -h voor groottes met achtervoegsel, -n voor gewone getallen, -V voor versie- en releasenummers, -g alleen voor wetenschappelijke notatie.
• Gebruik ISO-datums en je hebt geen datumsortering nodig. YYYY-MM-DD HH:MM:SS sorteert correct als gewone tekst, in elke locale, zonder opties.
• Wees voorzichtig met -u als je ook een sleutel of een sorteeroptie hebt opgegeven. Het houdt een willekeurige regel per groep over. Bedoel je "verwijder exacte duplicaten", gebruik dan een kale LC_ALL=C sort -u.
• Controleer voordat je samenvoegt. sort -m vertrouwt zijn invoer volledig en levert geruisloos rommel op als die invoer niet gesorteerd is. sort -C is een goedkope bewaker.
• Top het geheugen van grote sorteringen af, en top het laag af: -S 50M -T /var/tmp. De standaardinstelling pakt wat het nodig heeft (hier 691 MB voor een bestand van 62 MB) en een kleine buffer evenaarde dat precies, want het enige wat telt is het aantal runs onder de batchgrootte krijgen. De tijdelijke bestanden gaan naar /tmp, vaak het kleinste bestandssysteem dat je hebt.
• Tel bij een sortering die naar schijf uitwijkt verplaatste bytes, geen seconden. Elke samenvoegronde leest en herschrijft de volledige gegevensset. Daarom helpt -S en daarom doet --batch-size verlagen pijn (paragraaf 6.8).
• Voeg nooit brokken samen die volgens verschillende regels zijn gesorteerd. -m gaat uit van een volgorde over alle invoer. Zet LC_ALL=C en dezelfde sleutel aan de kant die de brokken schrijft en aan de kant die ze samenvoegt.
• Filter voor je sorteert, niet erna. grep, cut en awk streamen en kosten niets; sort buffert alles.
• Gebruik -z met find -print0 en xargs -0 zodra bestandsnamen ergens vandaan komen waar jij niet over gaat.
• Wees attent op gedeelde servers. Een grote sortering pakt standaard acht kernen. --parallel=2 en nice houden de rest van de machine bruikbaar.
• Voeg --compress-program niet toe zonder te meten. Op snelle lokale opslag maakt het sorteren enkele keren trager.
• Lees de handleiding eenmaal door. Hij is kort, en de schreeuwende waarschuwing onderaan is de belangrijkste zin over dit commando.

$ man 1 sort
$ sort --help              # the KEYDEF paragraph at the bottom is the useful part
$ info coreutils 'sort invocation'
$ man 1 uniq               # sort's constant companion
$ man 1 comm ; man 1 join  # both need matching sort orders
$ man 1 shuf ; man 1 tsort

10. Samenvatting

sort ziet eruit als het eenvoudigste commando in de gereedschapskist en is een van de subtielste. Alles wat er onhandig aan is komt voort uit drie feiten, en zodra je die drie in je hoofd hebt, houdt de rest op verrassend te zijn.

Het leent zijn volgorde uit de omgeving. Er is geen ingebouwde alfabetische volgorde; er is LC_COLLATE, en dat verschilt tussen je shell, je cronjob, je container en de laptop van je collega, en het veranderde in 2018 voor iedereen.

Het vergelijkt een sleutel, geen regel. De standaardsleutel is toevallig de hele regel, en dat verbergt het onderscheid totdat je je eerste -k schrijft en het misgaat.

Het moet alles lezen voordat het iets kan afdrukken. Die ene beperking levert het geheugengebruik op, de tijdelijke bestanden, het ontbrekende streamgedrag, en de reden waarom filteren voor het sorteren de moeite waard is.

• export LC_ALL=C in elk script dat sorteert. Overal dezelfde uitvoer, immuun voor OS-upgrades, en ongeveer twee keer zo snel.
• Schrijf -k2,2, niet -k2. Zonder het eindveld loopt de sleutel door tot het einde van de regel, en dat is bijna nooit wat je bedoelde.
• Zet de sorteerletter op de sleutel, zoals in -k3,3n. Een globale -n plet je tekstsleutels tot nul.
• --debug beslecht elke discussie over dit commando. Het onderstreept de bytes die worden vergeleken, noemt de locale, en zegt no match for key als je sleutel leeg is.
• Kies de juiste numerieke sortering: -h voor 1.4G, -n voor gewone getallen, -V voor log.2 voor log.10, -g alleen voor 1e3.
• sort | uniq -c | sort -rn | head beantwoordt de meeste logvragen. De eerste sort staat er zodat uniq kan werken.
• sort bestand > bestand leegt het bestand. Gebruik sort -o bestand bestand, dat sinds Version 4 Unix veilig is.
• -u houdt een willekeurige regel per gelijke groep over, niet de kleinste, en met -f, -n of een sleutel is "gelijk" veel breder dan "identiek".
• Gelijkspel wordt niet met rust gelaten: sort vergelijkt als laatste redmiddel de hele regel. -s zet dat uit en houdt de invoervolgorde aan.
• -m voegt samen zonder te controleren. Bewaak het met -C, dat 1 teruggeeft voor "niet gesorteerd" en 2 voor een echte fout.
• Grote sorteringen kosten ongeveer elf keer de bestandsgrootte aan RAM en wijken uit naar /tmp. -S 50M -T /var/tmp is de oplossing, en het is geen compromis: een kleine buffer evenaarde de snelheid van de standaardinstelling met een dertiende van het geheugen. Eerst filteren is nog beter.
• Als het uitwijkt, wordt het een external merge sort: gesorteerde runs op schijf, 16 tegelijk samengevoegd. Tel verplaatste bytes in plaats van seconden, want elke extra samenvoegronde herschrijft de volledige gegevensset (123 MB in het geheugen, 247 MB met een ronde, 365 MB met twee).
• Het is sinds 2010 multithreaded en wint niets meer voorbij 8 threads: 1,87 s bij --parallel=1, 0,79 s bij 8, en 0,79 s bij 16.
• -R is geen shuf, sort -t, is geen CSV-parser, en tsort is een heel ander commando dat afhankelijkheden oplost.

Dit is het spiekbriefje dat je wilt bewaren:

THE ONES TO REMEMBER
sort | uniq -c | sort -rn | head    what appears most often
LC_ALL=C sort                       same order everywhere, and faster
sort -o file file                   sort in place  ( > file EMPTIES it )
sort --debug ...                    show me the key you are actually using

ORDERING
-n    plain numbers          -h    1023 < 2K < 900M < 1.4G
-g    also 1e3, inf, nan     -V    log.2 before log.10, and IPv4
-r    reverse EVERY key      -M    Jan Feb Mar (locale month names)
-f    ignore case            -b    ignore leading blanks
-d    letters/digits only    -i    ignore control characters

KEYS   -k F[.C][OPTS][,F[.C][OPTS]]
-k2      field 2 TO END OF LINE      <- almost never what you want
-k2,2    field 2 only                <- write this
-k3,3n   field 3, numeric            <- letter ON the key, not global
-k1,1 -k3,3nr   name up, number down
-k1.6,1.7       field 1, characters 6-7
-t:      one literal separator; repeats make EMPTY fields
default  a RUN of blanks is one separator

MODES
-u    keep one line per equal group  (arbitrary; disables last resort)
-s    stable: equal lines keep input order
-c    is it sorted?   -C  same, quietly.  exit 1 = no, 2 = error
-cu   is it sorted AND free of duplicates?
-m    merge pre-sorted files; checks NOTHING, and assumes every
      input used the SAME locale and the SAME key

BIG FILES   ( when it does not fit: sorted runs on disk, merged 16 at a time )
-S 50M         cap the buffer LOW; matched the default at 1/13th the RAM
-T /var/tmp    spill here, not /tmp   ( needs ~1x the input, plus the output )
--parallel=2   be polite on a shared box   ( default caps at 8 )
--compress-program=gzip   only if temp SPACE is the problem; costs speed
--batch-size   leave it alone. lowering it multiplies the bytes moved
every merge pass re-reads AND re-writes everything: 2x, 4x, 6x the file

SAFE FILENAMES
find . -print0 | sort -z | xargs -0 ...

TEAMMATES
uniq -c/-d/-u   comm -12/-23/-13   join   shuf   tsort

LC_ALL=C for programs.  The locale for people.  --debug when in doubt.

Meestal is sort een commando van vijf seconden dat precies doet wat je verwacht. De ellende begint zodra de uitvoer ergens anders in gaat: een vergelijking met de lijst van gisteren, een comm tegen een backup, een ontdubbelde export, een nachtelijke taak die twee jaar prima liep en na een upgrade omvalt. Dat zijn de momenten waarop de volgorde belangrijker is dan het sorteren, en ze zijn meestal goedkoper te voorkomen dan te onderzoeken. Heb je een server waar een geplande taak stilletjes het verkeerde antwoord is gaan geven, en kan niemand zeggen wat er veranderd is, dan is dat precies het soort rustige werk waar ik graag bij help.