docs/cut
view cut.txt @ 17:08f539a5445d
Ueberarbeitung der Formulierungen, hauptsaechlich
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Wed, 13 May 2015 07:18:16 +0200 |
| parents | 4d8196c836d8 |
| children | b1e7b45fb3c8 |
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 noch die omnipraesente Zeichenkodierung
51 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 Wenn auch der Bytemodus neu eingefuehrt 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 also 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 koennen Felder ausgewaehlt werden. Das Trennzeichen (per
78 Default der Tab) kann mit `-d' geaendert werden.
80 Der typische Anwendungsfall fuer cut im Feldmodus ist die
81 Auswahl von Information aus der passwd-Datei. So z.B. der
82 Benutzername und seine ID:
84 $ cut -d: -f1,3 /etc/passwd
85 root:0
86 bin:1
87 daemon:2
88 mail:8
89 ...
91 (Die Argumente fuer die Optionen koennen bei cut uebrigens
92 mit Whitespace abgetrennt oder direkt angehaengt folgen.)
94 Dieser Feldmodus 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 bei cut nur genau ein Zeichen sein. Es kann
99 also nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
100 werden. 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 deshalb Erweiterungen, die das gewuenschte Verhalten
106 fuer 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 von Version 8 Unix wiederzugeben: ``In data base
120 parlance, it projects a relation.''
121 [ http://man.cat-v.org/unix_8th/1/cut
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 SCCS-ID 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 fruehester
150 Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
151 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
152 als Teil der Spezialversion 4.3BSD-UWisc,
153 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
154 die im Januar 1987 veroeffentlicht wurde.
155 Die Implementierung unterscheidet sich nur minimal von der
156 in System III.
157 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
158 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
159 ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
160 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
161 aufgenommen wurde.
162 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
163 Seine Manpage
164 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
165 erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
166 Nun muss man wissen, dass POSIX.2 erst im September
167 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
168 Manpage und das Programm geschrieben worden waren. Das Programm
169 wurde folglich anhand von Arbeitsversionen des Standards
170 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
171 In der Funktion zum parsen der Feldauswahlliste findet sich
172 dieser Kommentar:
174 This parser is less restrictive than the Draft 9 POSIX spec.
175 POSIX doesn't allow lists that aren't in increasing order or
176 overlapping lists.
178 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits
179 ein:
181 The elements in list can be repeated, can overlap, and can
182 be specified in any order.
184 Auch listet Draft 11.2 alle drei Modi, waehrend in diesem
185 BSD cut nur die zwei alten implementiert sind. Es koennte also
186 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
187 Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
188 leider nicht moeglich, diese Vermutung zu pruefen. XXX
190 Die Versionsnummern und Aenderungsdaten der aelteren
191 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
192 damaligen Versionskontrollsystem in den Code eingefuegt wurden,
193 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
195 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
197 Copyright (C) 1997-2015 Free Software Foundation, Inc.
198 Copyright (C) 1984 David M. Ihnat
200 Der Code hat also recht alte Urspruenge. Wie aus weiteren
201 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
202 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
203 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
204 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
205 Copyright-Vermerk auftauchen, ist unklar.
207 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
208 aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
209 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
210 so war Unix doch schon ueber zehn Jahre alt, als cut das
211 erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht
212 zu Version 7 Unix, das die Ausgangsbasis aller modernen
213 Unix-Systeme darstellt. Die weit komplexeren Programme sed
214 und awk waren dort schon vertreten. Man muss sich also
215 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
216 schon zwei Programme gab, die die Funktion von cut abdecken
217 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
218 die damit verbundene Geschwindigkeit gegenueber dem damals
219 traegen awk. Diese schlanke Gestalt ist es auch, die der
220 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
221 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
222 standardisiert und ist heutzutage ueberall anzutreffen.
224 Die urspruengliche Variante (ohne -b) wurde schon 1985 in
225 der System V Interface Definition, einer wichtigen formalen
226 Beschreibung von UNIX System V, spezifiziert und tauchte
227 anschliessend in allen relevanten Standards auf. Mit POSIX.2
228 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
229 (mit -b) standardisiert.
230 XXX sicher?
233 Multibyte-Unterstuetzung
235 Nun sind der Bytemodus und die damit verbundene
236 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
237 1992 standardisiert, wie steht es aber mit deren Umsetzung?
238 Welche Versionen implementieren POSIX korrekt?
239 Die Situation ist dreiteilig: Es gibt historische
240 Implementierungen, die nur -c und -f kennen. Dann gibt es
241 Implementierungen die -b zwar kennen, es aber lediglich als Alias
242 fuer -c handhaben. Diese Implementierungen funktionieren mit
243 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
244 Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
245 wie -b (und -n wird ignoriert). Schliesslich gibt es noch
246 Implementierungen, die -b und -c tatsaechlich POSIX-konform
247 implementieren.
249 Historische Zwei-Modi-Implementierungen sind z.B. die von
250 System III, System V und die aller BSDs bis in die 90er.
252 Pseudo-Multibyte-Implementierungen bieten GNU und die
253 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
254 ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
255 Teilweise findet man erst nach genauerer Suche heraus, dass
256 -c und -n nicht wie erwartet funktionieren; teilweise machen es
257 sich die Systeme auch einfach, indem sie auf
258 Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
259 klar darlegen:
261 Since we don't support multi-byte characters, the -c and -b
262 options are equivalent, and the -n option is meaningless.
264 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
266 Tatsaechlich standardkonforme Implementierungen, die
267 Multibytes korrekt handhaben, bekommt man bei einem modernen
268 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
269 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
270 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
271 Warum die beiden anderen grossen BSDs diese Aenderung nicht
272 uebernommen haben, bleibt offen. Es scheint aber an der im
273 obigen Kommentar formulierten Grundausrichtung zu liegen.
275 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
276 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
277 entscheidend, ob das System selbst mit einem Multibyte-Encoding
278 arbeitet, denn tut es das nicht, dann entsprechen sich
279 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
280 herausfinden indem man sich das Locale anschaut, aber einfacher
281 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
282 auszugeben und zu schauen ob dieses in einem oder in mehreren
283 Bytes kodiert ist:
285 $ echo ä | od -c
286 0000000 303 244 \n
287 0000003
289 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
290 Zeilenumbruch fuegt echo(1) hinzu.)
292 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
293 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
294 bei Latin1 und wie sie bei UTF-8 aussieht.
296 $ echo ä | iconv -t latin1 | od -c
297 0000000 344 \n
298 0000002
300 $ echo ä | iconv -t utf8 | od -c
301 0000000 303 244 \n
302 0000003
304 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
305 wird recht sicher einer dieser beiden Ausgaben entsprechen.
307 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
308 dann sollte sich eine POSIX-konforme Implementierung folgendermassen
309 verhalten:
311 $ echo ä | ./cut -c 1 | od -c
312 0000000 303 244 \n
313 0000003
315 $ echo ä | ./cut -b 1 | od -c
316 0000000 303 \n
317 0000002
319 $ echo ä | ./cut -b 1 -n | od -c
320 0000000 \n
321 0000001
323 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
324 allen drei Faellen wie die mittlere: Es wird das erste Byte
325 ausgegeben.
328 Implementierungen
330 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
331 Implementierungen.
333 Fuer einen ersten Eindruck ist der Umfang des Quellcodes
334 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
335 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
336 bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
337 erfordert zwangslaeufig mehr Code, deshalb sind diese
338 Implementierungen tendenziell umfangreicher.
341 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie
342 -----------------------------------------------------------------
343 116 123 2966 System III 1980-04-11 (hist)
344 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist)
345 200 256 5715 4.3BSD-Reno 1990-06-25 (hist)
346 200 270 6545 NetBSD 1993-03-21 (hist)
347 218 290 6892 OpenBSD 2008-06-27 (pseudo)
348 224 296 6920 FreeBSD 1994-05-27 (hist)
349 232 306 7500 NetBSD 2014-02-03 (pseudo)
350 340 405 7423 Heirloom 2012-05-20 (POSIX)
351 382 586 14175 GNU coreutils 1992-11-08 (pseudo)
352 391 479 10961 FreeBSD 2012-11-24 (POSIX)
353 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
356 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
357 urspruenglichen Implementierungen, die sich nur minimal
358 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
359 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
360 die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
361 moderne GNU-Variante mit fast 600 SLOCs.
363 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
364 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
365 -l') erstreckt sich ueber einen Faktor von 1.06 bei den aeltesten
366 Vertretern bis zu Faktor 1.5 bei GNU. Der groesste
367 Einflussfaktor darauf sind Leerzeilen, reine Kommentarzeilen und
368 die Groesse des Lizenzblocks am Dateianfang.
370 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
371 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
372 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
373 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
374 fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren
375 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
376 Ob man die Heirloom-Implementierung als besonders kryptisch
377 oder als besonders elegant bezeichnen will, das soll der
378 eigenen Einschaetzung des Lesers ueberlassen bleiben.
381 Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
382 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
383 verarbeitet, gibt es im Normalfall eine Funktion, die die
384 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
385 haben fast alle Implementierungen separate Funktionen fuer die
386 zwei bzw. drei Modi. Bei den POSIX-konformen Implementierungen
387 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
388 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
389 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
390 wird ausser den Fehlerausgaben alles in der main-Funktion
391 erledigt.
393 Cut-Implementierungen haben typischerweise zwei limitierende
394 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
395 Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt.
396 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
397 Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
398 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
399 Heirloom kann sowohl die Felderanzahl als auch die maximale
400 Zeilenlaenge beliebig gross werden; der Speicher dafür wird
401 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
402 Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
403 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
404 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
405 gross genug sein sollte.
408 Beschreibungen
410 Interessant ist auch ein Vergleich der Kurzbeschreibungen von
411 cut, wie sie sich in der Titelzeile der Manpages oder manchmal
412 auch am Anfang der Quellcodedatei finden. Die folgende Liste
413 ist grob zeitlich geordnet und nach Abstammung gruppiert:
416 System III cut out selected fields of each line of a file
417 System III (src) cut and paste columns of a table (projection of a relation)
418 System V cut out selected fields of each line of a file
419 HP-UX cut out (extract) selected fields of each line of a file
421 4.3BSD-UWisc (src) cut and paste columns of a table (projection of a relation)
422 4.3BSD-Reno select portions of each line of a file
423 NetBSD select portions of each line of a file
424 OpenBSD 4.6 select portions of each line of a file
425 FreeBSD 1.0 select portions of each line of a file
426 FreeBSD 10.0 cut out selected portions of each line of a file
427 SunOS 4.1.3 remove selected fields from each line of a file
428 SunOS 5.5.1 cut out selected fields of each line of a file
430 Heirloom Tools cut out selected fields of each line of a file
431 Heirloom Tools (src) cut out fields of lines of files
433 GNU coreutils remove sections from each line of files
435 Minix select out columns of a file
437 Version 8 Unix rearrange columns of data
438 ``Unix Reader'' rearrange columns of text
440 POSIX cut out selected fields of each line of a file
443 Die mit ``(src)'' markierten Beschreibungen sind aus dem
444 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
445 die Beschreibung des Standards. Der ``Unix Reader'' ist ein
446 rueckblickendes Textdokument von Doug McIlroy, das das
447 Auftreten von Tools in der Geschichte des Research Unix zum
448 Thema hat.
449 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
450 Eigentlich sollte seine Beschreibung der in Version 8 Unix
451 entsprechen. Die Abweichung koennte sowohl ein
452 Uebertragungsfehler als auch eine nachtraegliche Korrektur
453 sein. Alle uebrigen Beschreibungen entstammen den Manpages.
455 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
456 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
457 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
459 Interessant ist, dass die GNU coreutils seit Anbeginn vom
460 Entfernen von Teilen der Eingabe sprechen, wohingegen die
461 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
462 Worte ``cut out'' sind vielleicht auch etwas zu
463 missverstaendlich. HP-UX hat sie deshalb praezisiert.
465 Auch beim Begriff, was selektiert wird, ist man sich
466 uneins. Die Einen reden von Feldern (POSIX), Andere von
467 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
468 (Research Unix). Ironischerweise leistet sich gerade Version
469 8 Unix, das eigentlich um eine sehr treffende Weltsicht
470 bemueht ist, mit ``rearrange columns of data'' die
471 unzutreffendste der Beschreibungen.
474 Autoreninfo
476 Markus Schnalke interessiert sich fuer die Hintergruende
477 von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses
478 Textes wurde er regelrecht zum Historiker.
481 Lizenz
483 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
484 veroeffentlicht werden)