docs/cut
view cut.txt @ 22:4193939c6a24
Vorgeschichte um CB Unix erweitert
Zudem noch fehlende Links eingefuegt.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 31 May 2015 20:13:22 +0200 |
| parents | bac481be86d7 |
| children | a4ab235c304c |
line source
1 cut - cut out selected fields of each line of a file
2 ----------------------------------------------------
3 markus schnalke <meillo@marmaro.de>
4 2015-05
7 Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
8 In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
9 es, denn es ist ein schönes, praktisches und anschauliches
10 Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
11 werden.
14 Funktionsweise
16 Ursprünglich hatte cut zwei Modi, die später um einen dritten
17 erweitert wurden. Cut schneidet entweder gewünschte Zeichen aus
18 den Zeilen der Eingabe oder gewünschte, durch Trennzeichen
19 definierte, Felder.
21 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
22 zerteilen. Man kann damit beispielsweise bestimmte
23 Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in
24 diesem Beispiel die Rechte des Besitzers:
26 $ ls -l foo
27 -rw-rw-r-- 1 meillo users 0 May 12 07:32 foo
29 $ ls -l foo | cut -c 2-4
30 rw-
32 Oder die Schreibrechte des Besitzers, der Gruppe und der
33 Welt:
35 $ ls -l | cut -c 3,6,9
36 ww-
38 Mit cut lassen sich aber auch Strings kürzen.
40 $ long=12345678901234567890
41 $ echo "$long" | cut -c -10
42 1234567890
44 Dieser Befehl gibt die ersten maximal 10 Zeichen von
45 `$long' aus. (Alternativ kann man hierfür `printf
46 "%.10s\n" "$long"' verwenden.)
48 Geht es aber nicht um die Darstellung von Zeichen, sondern um
49 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
50 Früher, als US-ASCII noch die omnipräsente Zeichenkodierung
51 war, wurde jedes Zeichen mit genau einem
52 Byte gespeichert. Somit selektierte `cut -c' gleichermaßen
53 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
54 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
55 dieser Annahme lösen. In diesem Zug bekam cut mit
56 POSIX.2-1992 einen Bytemodus (Option `-b'). Will man
57 also nur die ersten maximal 500 Bytes vor dem
58 Newline-Zeichen stehen haben (und den Rest stillschweigend
59 ignorieren), dann macht man das mit:
61 $ cut -b -500
63 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese
64 Funktion ist insbesondere für POSIX wichtig, da man damit
65 Textdateien mit begrenzter Zeilenlänge erzeugen kann.
66 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
68 Wenn auch der Bytemodus neu eingeführt worden war, so sollte
69 er sich doch nur so verhalten wie der alte Zeichenmodus
70 normalerweise schon implementiert war. Beim Zeichenmodus aber
71 wurde eine neue Implementierungsweise gefordert. Das Problem
72 war folglich nicht, den neuen Bytemodus zu implementieren, sondern
73 den Zeichenmodus neu zu implementieren.
75 Neben dem Zeichen- und Bytemodus bietet cut noch den
76 Feldmodus, den man mit `-f' einleitet. Mit ihm
77 können Felder ausgewählt werden. Das Trennzeichen (per
78 Default der Tab) kann mit `-d' geändert werden. Es gilt in
79 gleicher Weise für die Eingabe und die Ausgabe.
81 Der typische Anwendungsfall für cut im Feldmodus ist die
82 Auswahl von Information aus der passwd-Datei. Hier z.B. der
83 Benutzername und seine ID:
85 $ cut -d: -f1,3 /etc/passwd
86 root:0
87 bin:1
88 daemon:2
89 mail:8
90 ...
92 (Die Argumente für die Optionen können bei cut übrigens
93 mit Whitespace abgetrennt oder direkt angehängt folgen.)
95 Dieser Feldmodus ist für einfache tabellarische Dateien,
96 wie eben die passwd, gut geeignet. Er kommt aber schnell an
97 seine Grenzen. Gerade der häufige Fall, dass an Whitespace
98 in Felder geteilt werden soll, wird damit nicht abgedeckt.
99 Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
100 demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
101 werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander
102 stehende Trennzeichen führen zu einem leeren Feld. Dieses
103 Verhalten widerspricht den Erwartungen, die man an die
104 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
105 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
106 haben deshalb Erweiterungen, die das gewünschte Verhalten
107 für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
108 man portabel bleiben will, verwendet man awk in diesen
109 Fällen.
111 Awk bietet noch eine weitere Funktion, die cut missen
112 lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
113 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
114 Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt
115 der Aufruf
116 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
117 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
118 der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
119 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
120 hierbei immer gleich geordnet wie in der Eingabe. Um die Worte
121 der Manpage von Version 8 Unix wiederzugeben: ``In data base
122 parlance, it projects a relation.''
123 [ http://man.cat-v.org/unix_8th/1/cut
124 Cut führt demnach die Datenbankoperation Projektion auf
125 Textdateien aus. Die Wikipedia erklärt das folgendermaßen:
127 Die Projektion entspricht der Projektionsabbildung aus der
128 Mengenlehre und kann auch Attributbeschränkung genannt
129 werden. Sie extrahiert einzelne Attribute aus der
130 ursprünglichen Attributmenge und ist somit als eine Art
131 Selektion auf Spaltenebene zu verstehen, das heißt, die
132 Projektion blendet Spalten aus.
134 [ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
137 Geschichtliches
139 Cut erblickte 1982 mit dem Release von UNIX System III das
140 Licht der öffentlichen Welt. Wenn man die Quellen von System
141 III durchforstet, findet man cut.c mit dem Zeitstempel 1980-04-11.
142 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
143 Das ist die älteste Implementierung des Programms, die ich
144 aufstöbern konnte. Allerdings spricht die SCCS-ID im
145 Quellcode von Version 1.5. Die Vorgeschichte liegt, der Vermutung
146 Doug McIlroys
147 [ http://minnie.tuhs.org/pipermail/tuhs/2015-May/004083.html
148 zufolge, in PWB/UNIX, dessen Entwicklungslinie die Grundlage für
149 System III war. In den von PWB 1.0 (1977) verfügbaren Quellen
150 [ http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/
151 ist cut noch nicht zu finden. Von PWB 2.0 sind mir keine
152 verfügbaren Quellen oder hilfreiche Dokumentation bekannt.
153 PWB 3.0 wurde später aus Marketinggründen als System III
154 bezeichnet. Eine Nebenlinie zu PWB war CB Unix, das nur innerhalb
155 der Bell Labs genutzt wurde. Das Handbuch von CB Unix Edition 2.1
156 vom November 1979 enthält bereits eine Manpage für cut.
157 [ ftp://sunsite.icm.edu.pl/pub/unix/UnixArchive/PDP-11/Distributions/other/CB_Unix/cbunix_man1_02.pdf
158 Eine frühere Erwähnung von cut als diese habe ich nicht gefunden.
160 Nun ein Blick auf die BSD-Linie: Dort ist mein frühester
161 Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
162 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
163 als Teil der Spezialversion 4.3BSD-UWisc,
164 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
165 die im Januar 1987 veröffentlicht wurde.
166 Die Implementierung unterscheidet sich nur minimal von der
167 in System III.
168 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
169 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
170 ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
171 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
172 aufgenommen wurde.
173 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
174 Seine Manpage
175 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
176 erwähnt bereits die erwartete Konformität mit POSIX.2.
177 Nun muss man wissen, dass POSIX.2 erst im September
178 1992 veröffentlicht wurde, erst gut zwei Jahren nachdem die
179 Manpage und das Programm geschrieben worden waren. Das Programm
180 wurde folglich anhand von Arbeitsversionen des Standards
181 implementiert. Ein Blick in den Code bekräftigt diese Vermutung.
182 In der Funktion zum parsen der Feldauswahlliste findet sich
183 dieser Kommentar:
185 This parser is less restrictive than the Draft 9 POSIX spec.
186 POSIX doesn't allow lists that aren't in increasing order or
187 overlapping lists.
189 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits
190 ein:
192 The elements in list can be repeated, can overlap, and can
193 be specified in any order.
195 Zudem listet Draft 11.2 alle drei Modi, während in diesem
196 BSD cut nur die zwei alten implementiert sind. Es könnte also
197 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
198 Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
199 leider nicht möglich, diese Vermutung zu prüfen.
201 Die Versionsnummern und Änderungsdaten der älteren
202 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
203 damaligen Versionskontrollsystem in den Code eingefügt wurden,
204 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
206 Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:
208 Copyright (C) 1997-2015 Free Software Foundation, Inc.
209 Copyright (C) 1984 David M. Ihnat
211 Der Code hat also recht alte Ursprünge. Wie aus weiteren
212 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
213 MacKenzie und später von Jim Meyering überarbeitet. Letzterer
214 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
215 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
216 Copyright-Vermerk auftauchen, ist unklar.
218 Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut,
219 aus Sicht des ursprünglichen Unix, zu den jüngeren Tools.
220 Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist,
221 so war Unix doch schon über zehn Jahre alt, als cut das
222 erste Mal auftauchte. Insbesondere gehörte cut noch nicht
223 zu Version 7 Unix, das die Ausgangsbasis aller modernen
224 Unix-Systeme darstellt. Die weit komplexeren Programme sed
225 und awk waren dort schon vertreten. Man muss sich also
226 fragen, warum cut überhaupt noch entwickelt wurde, wo es
227 schon zwei Programme gab, die die Funktion von cut abdecken
228 konnten. Ein Argument für cut war sicher seine Kompaktheit und
229 die damit verbundene Geschwindigkeit gegenüber dem damals
230 trägen awk. Diese schlanke Gestalt ist es auch, die der
231 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
232 Cut überzeugte. Es wurde in andere Unix Varianten übernommen,
233 standardisiert und ist heutzutage überall anzutreffen.
235 Die ursprüngliche Variante (ohne -b) wurde schon 1985 in
236 der System V Interface Definition, einer wichtigen formalen
237 Beschreibung von UNIX System V, spezifiziert und tauchte
238 anschließend in allen relevanten Standards auf. Mit POSIX.2
239 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
240 (mit -b) standardisiert.
243 Multibyte-Unterstützung
245 Nun sind der Bytemodus und die damit verbundene
246 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
247 1992 standardisiert, wie steht es aber mit deren Umsetzung?
248 Welche Versionen implementieren POSIX korrekt?
249 Die Situation ist dreiteilig: Es gibt historische
250 Implementierungen, die nur -c und -f kennen. Dann gibt es
251 Implementierungen die -b zwar kennen, es aber lediglich als Alias
252 für -c handhaben. Diese Implementierungen funktionieren mit
253 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
254 Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber
255 wie -b (und -n wird ignoriert). Schließlich gibt es noch
256 Implementierungen, die -b und -c tatsächlich POSIX-konform
257 implementieren.
259 Historische Zwei-Modi-Implementierungen sind z.B. die von
260 System III, System V und die aller BSDs bis in die 90er.
262 Pseudo-Multibyte-Implementierungen bieten GNU und die
263 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
264 ob dort ein Schein von POSIX-Konformität gewahrt wird.
265 Teilweise findet man erst nach genauerer Suche heraus, dass
266 -c und -n nicht wie erwartet funktionieren; teilweise machen es
267 sich die Systeme auch einfach, indem sie auf
268 Singlebyte-Zeichenkodierungen beharren, das aber dafür meist
269 klar darlegen:
271 Since we don't support multi-byte characters, the -c and -b
272 options are equivalent, and the -n option is meaningless.
274 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
276 Tatsächlich standardkonforme Implementierungen, die
277 Multibytes korrekt handhaben, bekommt man bei einem modernen
278 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
279 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
280 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
281 Warum die beiden anderen großen BSDs diese Änderung nicht
282 übernommen haben, bleibt offen. Es scheint aber an der im
283 obigen Kommentar formulierten Grundausrichtung zu liegen.
285 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
286 Systems Multibytes korrekt unterstützt werden? Zuerst ist
287 entscheidend, ob das System selbst mit einem Multibyte-Encoding
288 arbeitet, denn tut es das nicht, dann entsprechen sich
289 Zeichen und Bytes und die Frage erübrigt sich. Man kann das
290 herausfinden indem man sich das Locale anschaut, aber einfacher
291 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
292 auszugeben und zu schauen ob dieses in einem oder in mehreren
293 Bytes kodiert ist:
295 $ echo ä | od -c
296 0000000 303 244 \n
297 0000003
299 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
300 Zeilenumbruch fügt echo(1) hinzu.)
302 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
303 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
304 bei Latin1 und wie sie bei UTF-8 aussieht.
306 $ echo ä | iconv -t latin1 | od -c
307 0000000 344 \n
308 0000002
310 $ echo ä | iconv -t utf8 | od -c
311 0000000 303 244 \n
312 0000003
314 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
315 wird recht sicher einer dieser beiden Ausgaben entsprechen.
317 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
318 dann sollte sich eine POSIX-konforme Implementierung folgendermaßen
319 verhalten:
321 $ echo ä | cut -c 1 | od -c
322 0000000 303 244 \n
323 0000003
325 $ echo ä | cut -b 1 | od -c
326 0000000 303 \n
327 0000002
329 $ echo ä | cut -b 1 -n | od -c
330 0000000 \n
331 0000001
333 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
334 allen drei Fällen wie die mittlere: Es wird das erste Byte
335 ausgegeben.
338 Implementierungen
340 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
341 Implementierungen.
343 Für einen ersten Eindruck ist der Umfang des Quellcodes
344 hilfreich. Typischerweise steigt dieser über die Jahre an. Diese
345 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
346 bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
347 erfordert zwangsläufig mehr Code, deshalb sind diese
348 Implementierungen tendenziell umfangreicher.
351 SLOC Zeilen Bytes Gehört zu Dateidatum Kategorie
352 -----------------------------------------------------------------
353 116 123 2966 System III 1980-04-11 (hist)
354 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist)
355 200 256 5715 4.3BSD-Reno 1990-06-25 (hist)
356 200 270 6545 NetBSD 1993-03-21 (hist)
357 218 290 6892 OpenBSD 2008-06-27 (pseudo)
358 224 296 6920 FreeBSD 1994-05-27 (hist)
359 232 306 7500 NetBSD 2014-02-03 (pseudo)
360 340 405 7423 Heirloom 2012-05-20 (POSIX)
361 382 586 14175 GNU coreutils 1992-11-08 (pseudo)
362 391 479 10961 FreeBSD 2012-11-24 (POSIX)
363 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
366 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
367 ursprünglichen Implementierungen, die sich nur minimal
368 unterscheiden, mit gut 100 SLOCs. (2) Die fünf BSD-Versionen mit
369 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
370 die alte GNU-Version mit 340-390 SLOCs. Und schließlich (4) die
371 moderne GNU-Variante mit fast 600 SLOCs.
373 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
374 SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (`wc
375 -l') erstreckt sich über eine Spanne von Faktor 1.06 bei den
376 ältesten Vertretern bis zu Faktor 1.5 bei GNU. Den größten
377 Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und
378 die Größe des Lizenzblocks am Dateianfang.
380 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
381 und der Dateigröße (`wc -c'), so pendelt das Teilnehmerfeld
382 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
383 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
384 fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren
385 Programmierstil, mit spezieller Einrückung und langen Bezeichnern.
386 Ob man die Heirloom-Implementierung
387 [ http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/cut/cut.c?revision=1.6&view=markup
388 als besonders kryptisch
389 oder als besonders elegant bezeichnen will, das soll der
390 eigenen Einschätzung des Lesers überlassen bleiben. Vor allem
391 der Vergleich mit einer GNU-Implementierung
392 [ http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cut.c;hb=e981643
393 ist eindrucksvoll.
396 Die interne Struktur der Programmcodes (in C) ist meist ähnlich.
397 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
398 verarbeitet, gibt es im Normalfall eine Funktion, die die
399 Feldauswahl in eine interne Datenstruktur überführt. Desweiteren
400 haben fast alle Implementierungen separate Funktionen für die
401 zwei oder drei Modi. Bei den POSIX-konformen Implementierungen
402 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
403 damit in einer eigenen Funktion umgesetzt. Nur bei der frühen
404 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
405 wird außer den Fehlerausgaben alles in der main-Funktion
406 erledigt.
408 Cut-Implementierungen haben typischerweise zwei limitierende
409 Größen: Die Maximalanzahl unterstützter Felder und die maximale
410 Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt.
411 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
412 Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
413 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
414 Heirloom kann sowohl die Felderanzahl als auch die maximale
415 Zeilenlänge beliebig groß werden; der Speicher dafür wird
416 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
417 Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die
418 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
419 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
420 groß genug sein sollte.
423 Beschreibungen
425 Interessant ist zudem ein Vergleich der Kurzbeschreibungen von
426 cut, wie sie sich in der Titelzeile der Manpages oder manchmal
427 am Anfang der Quellcodedatei finden. Die folgende Liste
428 ist grob zeitlich geordnet und nach Abstammung gruppiert:
431 CB Unix cut out selected fields of each line of a file
432 System III cut out selected fields of each line of a file
433 System III (src) cut and paste columns of a table (projection of a relation)
434 System V cut out selected fields of each line of a file
435 HP-UX cut out (extract) selected fields of each line of a file
437 4.3BSD-UWisc (src) cut and paste columns of a table (projection of a relation)
438 4.3BSD-Reno select portions of each line of a file
439 NetBSD select portions of each line of a file
440 OpenBSD 4.6 select portions of each line of a file
441 FreeBSD 1.0 select portions of each line of a file
442 FreeBSD 10.0 cut out selected portions of each line of a file
443 SunOS 4.1.3 remove selected fields from each line of a file
444 SunOS 5.5.1 cut out selected fields of each line of a file
446 Heirloom Tools cut out selected fields of each line of a file
447 Heirloom Tools (src) cut out fields of lines of files
449 GNU coreutils remove sections from each line of files
451 Minix select out columns of a file
453 Version 8 Unix rearrange columns of data
454 ``Unix Reader'' rearrange columns of text
456 POSIX cut out selected fields of each line of a file
459 Die mit ``(src)'' markierten Beschreibungen sind aus dem
460 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält
461 die Beschreibung im Standard. Der ``Unix Reader'' ist ein
462 rückblickendes Textdokument von Doug McIlroy, das das
463 Auftreten der Tools in der Geschichte des Research Unix zum
464 Thema hat.
465 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
466 Eigentlich sollte seine Beschreibung der in Version 8 Unix
467 entsprechen. Die Abweichung könnte ein Übertragungsfehler
468 oder eine nachträgliche Korrektur sein. Alle übrigen
469 Beschreibungen entstammen den Manpages.
471 Oft ist mit der Zeit die POSIX-Beschreibung übernommen
472 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
473 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
475 Interessant ist, dass die GNU coreutils seit Anbeginn vom
476 Entfernen von Teilen der Eingabe sprechen, wohingegen die
477 Kommandozeilenangabe klar ein Auswählen darstellt. Die
478 Worte ``cut out'' sind vielleicht auch zu missverständlich.
479 HP-UX hat sie deshalb präzisiert.
481 Beim Begriff, was selektiert wird, ist man sich ebenfalls
482 uneins. Die Einen reden von Feldern (POSIX), Andere von
483 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
484 (Research Unix). Ironischerweise leistet sich gerade Version
485 8 Unix, das eigentlich um eine sehr treffende Weltsicht
486 bemüht ist, mit ``rearrange columns of data'' die
487 unzutreffendste der Beschreibungen.
490 Autoreninfo
492 Markus Schnalke interessiert sich für die Hintergründe
493 von Unix und seinen Werkzeugen. Für die Erarbeitung dieses
494 Textes wurde er regelrecht zum Historiker.
497 Lizenz
499 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
500 veröffentlicht werden)