docs/cut
view cut.txt @ 15:77d1f55bba08
Weitere Ueberarbeitungen
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Tue, 12 May 2015 07:35:33 +0200 |
| parents | bf5e41260f89 |
| children | 4d8196c836d8 |
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 schoenes, praktisches und anschauliches
10 Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
11 werden.
14 Funktionsweise
16 Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten
17 erweitert wurden. Cut schneidet entweder gewuenschte Zeichen aus
18 den Zeilen der Eingabe oder gewuenschte, durch Trennzeichen
19 definierte, Felder.
21 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
22 zerteilen. So kann man 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 kuerzen.
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 hierfuer `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 Frueher, als US-ASCII als Zeichensatz und -kodierung
51 noch omnipraesent war, wurde jedes Zeichen mit genau einem
52 Byte gespeichert. Somit selektierte `cut -c' gleichermassen
53 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
54 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
55 dieser Annahme loesen. 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 fuer POSIX wichtig, da man so
65 Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
66 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
68 Auch wenn der Bytemodus neu eingefuehrt wurde, so sollte er
69 sich doch nur so verhalten wie der alte Zeichenmodus normalerweise
70 implementiert war. Beim Zeichenmodus aber wurde durch POSIX.2
71 eine andere Implementierungsweise gefordert. Das Problem war
72 also nicht, den neuen Bytemodus zu implementieren, sondern
73 den Zeichenmodus neu zu implementieren.
75 Neben dem Zeichen- und Byte-Modus bietet cut noch den
76 Feld-Modus, den man mit `-f' einleitet. Mit ihm
77 koennen Felder ausgewaehlt werden. Das Trennzeichen (per
78 Default der Tab) kann mit `-d' geaendert werden.
80 Der typische Anwendungsfall fuer cut im Feld-Modus ist die
81 Auswahl von Information aus der passwd-Datei. So z.B. der
82 Benutzername, seine ID und das Homeverzeichnis:
84 $ cut -d: -f1,3,6 /etc/passwd
85 root:0:/root
86 bin:1:/bin
87 daemon:2:/sbin
88 mail:8:/var/spool/mail
89 ...
91 (Die Argumente fuer die Optionen koennen bei cut uebrigens
92 mit Whitespace abgetrennt oder direkt angehaengt folgen.)
94 Dieser Feld-Modus ist fuer einfache tabellarische Dateien,
95 wie eben die passwd, gut geeignet. Er kommt aber schnell an
96 seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
97 in Felder geteilt werden soll, wird damit nicht abgedeckt.
98 Der Delimiter kann nur genau ein Zeichen sein. Es kann also
99 nicht sowohl an Leerzeichen als auch an Tabs getrennt werden.
100 Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
101 stehende Trennzeichen fuehren zu einem leeren Feld. Dieses
102 Verhalten widerspricht den Erwartungen, die man an die
103 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
104 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
105 haben aber Erweiterungen, die das gewuenschte Verhalten fuer
106 Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
107 man portabel bleiben will, verwendet man awk in diesen
108 Faellen.
110 Awk bietet noch eine weitere Funktion, die cut missen
111 laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
112 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
113 Feld kann selbst mehrfach angegeben werden. So gibt der Aufruf
114 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
115 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
116 der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
117 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
118 dabei immer gleich geordnet wie in der Eingabe. Um die Worte
119 der Manpage XXX von Version 8 Unix wiederzugeben: ``In data base
120 parlance, it projects a relation.''
121 [ XXX
122 Cut fuehrt also die Datenbankoperation Projektion auf
123 Textdateien aus. Die Wikipedia erklaert das folgendermassen:
125 Die Projektion entspricht der Projektionsabbildung aus der
126 Mengenlehre und kann auch Attributbeschränkung genannt
127 werden. Sie extrahiert einzelne Attribute aus der
128 ursprünglichen Attributmenge und ist somit als eine Art
129 Selektion auf Spaltenebene zu verstehen, das heißt, die
130 Projektion blendet Spalten aus.
132 [ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
135 Geschichtliches
137 Cut erblickte 1982 mit dem Release von UNIX System III das
138 Licht der oeffentlichen Welt. Wenn man die Quellen von System
139 III durchforstet, findet man die Quellcodedatei cut.c mit dem
140 Zeitstempel 1980-04-11.
141 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
142 Das ist die aelteste Manifestation des Programms, die ich
143 aufstoebern konnte. Allerdings spricht die sccsid im
144 Quellcode von Version 1.5. Es muss also noch eine
145 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
146 gefunden.
147 XXX mail an TUHS
149 Nun ein Blick auf die BSD-Linie: Dort ist mein
150 fruehester Fund ein cut.c mit dem Dateimodifikationsdatum
151 1986-11-07
152 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
153 als Teil der Spezialversion 4.3BSD-UWisc,
154 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
155 die im Januar 1987 veroeffentlicht wurde.
156 Die Implementierung unterscheidet sich nur minimal von der
157 in System III.
158 Im bekannteren 4.3BSD-Tahoe (1988) taucht cut nicht auf.
159 Das darauf folgende 4.3BSD-Reno (1990) liefert aber wieder
160 ein cut mit aus. Dieses cut ist ein von Adam S. Moskowitz und
161 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
162 aufgenommen wurde.
163 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
164 Seine Manpage
165 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
166 erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
167 XXX 2 oder 3 modi? Draft 9: 2 modi? Draft 11.2 hat 3 modi!
168 Nun sollte man wissen, dass POSIX.2 erst im September
169 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
170 Manpage und das Programm geschrieben wurden. Das Programm
171 wurde folglich anhand von Arbeitsversionen des Standards
172 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
173 In der Funktion zum parsen der Feldauswahlliste findet sich
174 dieser Kommentar:
176 This parser is less restrictive than the Draft 9 POSIX spec.
177 POSIX doesn't allow lists that aren't in increasing order or
178 overlapping lists.
180 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits
181 ein:
183 The elements in list can be repeated, can overlap, and can
184 be specified in any order.
186 Die Versionsnummern und Aenderungsdatums der aelteren
187 BSD-Implementierungen kann man aus den SCCS-IDs (die vom
188 damaligen Versionskontrollsystem in den Code eingefuegt wurden)
189 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
191 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
193 Copyright (C) 1997-2015 Free Software Foundation, Inc.
194 Copyright (C) 1984 David M. Ihnat
196 Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren
197 Kommentaren zu entnehmen ist, wurde der Code zuerst von David
198 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
199 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
200 Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk
201 auftauchen, ist unklar.
203 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
204 aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
205 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
206 so war Unix doch schon ueber zehn Jahre alt, als cut das
207 erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht
208 zu Version 7 Unix, das die Ausgangsbasis aller modernen
209 Unix-Systeme darstellt. Die weit komplexeren Programme sed
210 und awk waren dort schon vertreten. Man muss sich also
211 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
212 schon zwei Programme gab, die die Funktion von cut abdecken
213 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
214 die damit verbundene Geschwindigkeit gegenueber dem damals
215 traegen awk. Diese schlanke Gestalt ist es auch, die der Unix
216 Philosopie entspricht: Mache eine Aufgabe und die richtig!
217 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
218 standardisiert und ist heutzutage ueberall anzutreffen.
220 Die urspruengliche Variante (ohne -b) wurde schon 1985 in
221 der System V Interface Definition, einer wichtigen formalen
222 Beschreibung von UNIX System V, spezifiziert und tauchte
223 anschliessend in allen relevanten Standards auf. Mit POSIX.2
224 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
225 (mit -b) standardisiert.
226 XXX sicher?
229 Multibyte-Unterstuetzung
231 Nun sind der Bytemodus und die damit verbundene
232 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
233 1992 standardisiert, wie steht es aber mit deren Umsetzung?
234 Welche Versionen implementieren POSIX korrekt?
235 Die Situation ist dreiteilig: Es gibt traditionelle
236 Implementierungen, die nur -c und -f kennen. Dann gibt es
237 Implementierungen die -b zwar kennen, es aber lediglich als Alias
238 fuer -c handhaben. Diese Implementierungen funktionieren mit
239 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
240 Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
241 wie -b (und -n wird ignoriert). Schliesslich gibt es noch
242 Implementierungen, die -b und -c tatsaechlich POSIX-konform
243 implementieren.
245 Traditionelle Zwei-Modi-Implementierungen sind z.B. die von
246 System III, System V und die aller BSDs bis in die 90er.
248 Pseudo-Multibyte-Implementierungen bieten GNU und die
249 modernen NetBSDs und OpenBSDs. Man darf sich durchaus fragen,
250 ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
251 Teilweise findet man erst nach genauerer Suche heraus, dass
252 -c und -n nicht wie erwartet funktionieren; teilweise machen es
253 sich die System auch einfach, indem sie auf
254 Singlebyte-Zeichenkodierungen beharren, das aber dafuer klar
255 darlegen:
257 Since we don't support multi-byte characters, the -c and -b
258 options are equivalent, and the -n option is meaningless.
260 [ openbsd XXX
262 Tatsaechlich standardkonforme Implementierungen, die
263 Multibytes korrekt handhaben, bekommt man bei einem modernen
264 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
265 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
266 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
267 Warum die beiden anderen grossen BSDs diese Aenderung nicht
268 uebernommen haben, bleibt offen. Es scheint aber an der im
269 obigen Kommentar formulierten Grundausrichtung zu liegen.
271 Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen
272 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
273 entscheidend, ob das System selbst mit einem Multibyte-Encoding
274 arbeitet, denn tut es das nicht, dann entsprechen sich naemlich
275 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
276 herausfinden indem man sich das Locale anschaut, aber einfacher
277 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
278 auszugeben und zu schauen ob dieses in einem oder in mehreren
279 Bytes kodiert ist:
281 $ echo ä | od -c
282 0000000 303 244 \n
283 0000003
285 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
286 Zeilenumbruch fuegt echo(1) hinzu.)
288 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
289 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
290 bei Latin1 und wie sie bei UTF-8 aussieht.
292 $ echo ä | iconv -t latin1 | od -c
293 0000000 344 \n
294 0000002
296 $ echo ä | iconv -t utf8 | od -c
297 0000000 303 244 \n
298 0000003
300 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
301 wird recht sicher einer dieser beiden Ausgaben entsprechen.
303 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
304 dann sollte sich eine POSIX-konforme Implementierung so verhalten:
306 $ echo ä | ./cut -c 1 | od -c
307 0000000 303 244 \n
308 0000003
310 $ echo ä | ./cut -b 1 | od -c
311 0000000 303 \n
312 0000002
314 $ echo ä | ./cut -b 1 -n | od -c
315 0000000 \n
316 0000001
318 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
319 allen drei Faellen wie die mittlere: Es wird das erste Byte
320 ausgegeben.
323 Implementierungen
325 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
326 Implementierungen.
328 Fuer einen ersten Eindruck ist der Umfang des Quellcodes
329 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
330 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
331 bestaetigt werden. Die Unterstuetzung des Byte-Modus (-b)
332 erfordert zwangslaeufig mehr Code, deshalb sind die
333 POSIX-konformen Implementierungen tendenziell umfangreicher.
336 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie
337 -----------------------------------------------------------------
338 116 123 2966 System III 1980-04-11 (trad)
339 118 125 3038 4.3BSD-UWisc 1986-11-07 (trad)
340 200 256 5715 4.3BSD-Reno 1990-06-25 (trad)
341 200 270 6545 NetBSD 1993-03-21 (trad)
342 218 290 6892 OpenBSD 2008-06-27 (pseudo)
343 224 296 6920 FreeBSD 1994-05-27 (trad)
344 232 306 7500 NetBSD 2014-02-03 (pseudo)
345 340 405 7423 Heirloom 2012-05-20 (POSIX)
346 382 586 14175 GNU coreutils 1992-11-08 (pseudo)
347 391 479 10961 FreeBSD 2012-11-24 (POSIX)
348 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
349 XXX verlinken
352 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
353 urspruenglichen Implementierungen, die sich nur minimal
354 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
355 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
356 die alte GNU-Version mit 340-390 SLOCs. Und (4) die moderne
357 GNU-Variante mit fast 600 SLOCs.
359 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
360 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
361 -l') erstreckt sich ueber einen Faktor von 1.06 bei den aeltesten
362 Vertretern bis zu Faktor 1.5 bei GNU. Der groesste
363 Einflussfaktor darauf sind Leerzeilen, reine Kommentarzeilen und
364 die Groesse des Lizenzblocks am Dateianfang.
366 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
367 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
368 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
369 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
370 fast 40 nach oben. Dies liegt bei GNU hauptsaechlich an deren
371 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
372 Ob man die Heirloom-Implementierung als besonders kryptisch
373 oder als besonders elegant bezeichnen will, das soll der
374 eigenen Einschaetzung des Lesers ueberlassen bleiben.
377 Die interne Struktur des C-Codes ist meist aehnlich. Neben der
378 obligatorischen main-Funktion, die die Kommandozeilenargumente
379 verarbeitet, gibt es im Normalfall eine Funktion, die die
380 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
381 haben fast alle Implementierungen separate Funktionen fuer die
382 zwei bzw. drei Modi. Bei den POSIX-konformen Implementierungen
383 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
384 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
385 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
386 wird ausser den Fehlerausgaben nichts aus der main-Funktion
387 ausgelagert.
389 Cut-Implementierungen haben typischerweise zwei limitierende
390 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
391 Zeilenlaenge. Bei System III ist die Anzahl der moeglichen Felder
392 und ebenso die Zeilenlaenge auf 512 begrenzt. 4.3BSD-Reno und die
393 BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX
394 bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei
395 allen GNU-Implementierungen und bei Heirloom kann sowohl
396 die Felderanzahl als auch die maximale Zeilenlaenge beliebig
397 gross werden; der Speicher dafür wird dynamisch alloziiert.
398 OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber
399 beliebiger Zeilenlaenge. XXX fgetln
400 Die begrenzte Felderanzahl scheint jedeoch kein praktisches
401 Problem darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048
402 durchaus genug Platz bieten sollte.
405 Beschreibungen
407 Interessant ist auch ein Vergleich der Kurzbeschreibungen von
408 cut, wie sie sich in der Titelzeile von Manpages oder manchmal
409 auch am Anfang der Quellcodedatei finden. Die folgende Liste
410 ist grob zeitlich geordnet und nach Abstammung gruppiert:
413 System III cut out selected fields of each line of a file
414 System III (src) cut and paste columns of a table (projection of a relation)
415 System V cut out selected fields of each line of a file
416 HP-UX cut out (extract) selected fields of each line of a file
418 4.3BSD-UWisc (src) cut and paste columns of a table (projection of a relation)
419 4.3BSD-Reno select portions of each line of a file
420 NetBSD select portions of each line of a file
421 OpenBSD 4.6 select portions of each line of a file
422 FreeBSD 1.0 select portions of each line of a file
423 FreeBSD 10.0 cut out selected portions of each line of a file
424 SunOS 4.1.3 remove selected fields from each line of a file
425 SunOS 5.5.1 cut out selected fields of each line of a file
427 Heirloom Tools cut out selected fields of each line of a file
428 Heirloom Tools (src) cut out fields of lines of files
430 GNU coreutils remove sections from each line of files
432 Minix select out columns of a file
434 Version 8 Unix rearrange columns of data
435 ``Unix Reader'' rearrange columns of text
437 POSIX cut out selected fields of each line of a file
440 Die mit ``(src)'' markierten Beschreibungen sind aus dem
441 jeweiligen Quellcode entnommen.
442 Der POSIX-Eintrag enthaelt die Beschreibung des Standards.
443 Der ``Unix Reader'' ist ein rueckblickendes Textdokument von
444 Doug McIlroy, das das Auftreten von Tools in der Geschichte
445 des Research Unix zum Thema hat.
446 [ XXX
447 Eigentlich sollte seine
448 Beschreibung der in Version 8 Unix entsprechen. Die
449 Abweichung koennte sowohl ein Uebertragungsfehler als auch
450 eine nachtraegliche Korrektur sein.
451 Alle uebrigen Beschreibungen entstammen den Manpages.
453 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
454 worden, wie beispielsweise bei FreeBSD zu sehen.
455 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
456 XXX fixme!
458 Interessant ist, dass die GNU coreutils seit Anbeginn vom
459 Entfernen von Teilen der Eingabe sprechen, wohingegen die
460 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
461 Worte ``cut out'' sind vielleicht auch nur etwas zu
462 missverstaendlich. HP-UX hat sie deshalb praezisiert.
464 Auch beim Begriff, was selektiert wird, ist man sich
465 uneins. Die einen reden von Feldern (POSIX), andere von
466 Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten
467 (Research Unix). Ironischerweise leistet sich gerade Version
468 8 Unix, das eigentlich um eine sehr treffende Weltsicht
469 bemueht ist, mit ``rearrange columns of data'' die
470 unzutreffendste der Beschreibungen.
473 Autoreninfo
475 Markus Schnalke interessiert sich fuer die Hintergruende
476 von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses
477 Textes wurde er regelrecht zum Historiker.
480 Lizenz
482 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
483 veroeffentlicht werden)