»cut out selected fields of each line of a file«
Die Geschichte des Programms »cut« in Unix
Implementierungen
Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an Implementierungen.
Für einen ersten Eindruck ist der Umfang des Quellcodes hilfreich. Typischerweise steigt dieser über die Jahre an. Diese Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall, bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus erfordert zwangsläufig mehr Code, deshalb sind diese Implementierungen tendenziell umfangreicher.
| Verschiedene Implementierungen von cut | |||||
|---|---|---|---|---|---|
| SLOC | Zeilen | Bytes | Gehört zu | Dateidatum | Kategorie |
| 116 | 123 | 2966 | System III | 1980-04-11 | (hist) |
| 118 | 125 | 3038 | 4.3BSD-UWisc | 1986-11-07 | (hist) |
| 200 | 256 | 5715 | 4.3BSD-Reno | 1990-06-25 | (hist) |
| 200 | 270 | 6545 | NetBSD | 1993-03-21 | (hist) |
| 218 | 290 | 6892 | OpenBSD | 2008-06-27 | (pseudo) |
| 224 | 296 | 6920 | FreeBSD | 1994-05-27 | (hist) |
| 232 | 306 | 7500 | NetBSD | 2014-02-03 | (pseudo) |
| 340 | 405 | 7423 | Heirloom | 2012-05-20 | (POSIX) |
| 382 | 586 | 14175 | GNU coreutils | 1992-11-08 | (pseudo) |
| 391 | 479 | 10961 | FreeBSD | 2012-11-24 | (POSIX) |
| 588 | 830 | 23167 | GNU coreutils | 2015-05-01 | (pseudo) |
In der Tabelle mit »(hist)« bezeichnete Implementierungen beziehen sich auf ältere Implementierungen, die nur -c und -f kennen. Pseudo-Implementierungen, die -b zwar kennen, es aber nur als Alias für -c handhaben, sind mit »(pseudo)« gekennzeichnet. POSIX-konforme Implementierungen von cut sind mit »(POSIX)« markiert.
Das Kandidatenfeld teilt sich grob in vier Gruppen:
- Die zwei ursprünglichen Implementierungen, die sich nur minimal unterscheiden, mit gut 100 SLOCs
- Die fünf BSD-Versionen mit gut 200 SLOCs
- Die zwei POSIX-konformen Programme und die alte GNU-Version mit 340-390 SLOCs
- Und schließlich die moderne GNU-Variante mit fast 600 SLOCs
Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (wc -l) erstreckt sich über eine Spanne von Faktor 1,06 bei den ältesten Vertretern bis zu Faktor 1,5 bei GNU. Den größten Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und die Größe des Lizenzblocks am Dateianfang.
Betrachtet man die Abweichungen zwischen den logischen Codezeilen und der Dateigröße (wc -c), so pendelt das Teilnehmerfeld zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren Programmierstil, mit spezieller Einrückung und langen Bezeichnern. Ob man die Heirloom-Implementierung als besonders kryptisch oder als besonders elegant bezeichnen will, das soll der eigenen Einschätzung des Lesers überlassen bleiben. Vor allem der Vergleich mit einer GNU-Implementierung ist eindrucksvoll.
Die interne Struktur der Programmcodes (in C) ist meist ähnlich. Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente verarbeitet, gibt es im Normalfall eine Funktion, die die Feldauswahl in eine interne Datenstruktur überführt. Desweiteren haben fast alle Implementierungen separate Funktionen für jeden ihrer Modi. Bei den POSIX-konformen Implementierungen wird die Kombination -b -n als weiterer Modus behandelt und damit in einer eigenen Funktion umgesetzt. Nur bei der frühen System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) wird außer den Fehlerausgaben alles in der main-Funktion erledigt.
cut-Implementierungen haben typischerweise zwei limitierende Größen: Die Maximalanzahl unterstützter Felder und die maximale Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt. 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei Heirloom kann sowohl die Felderanzahl als auch die maximale Zeilenlänge beliebig groß werden; der Speicher dafür wird dynamisch alloziert. OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die begrenzte Felderanzahl scheint jedoch kein Praxisproblem darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus groß genug sein sollte.
