docs/cut
view cut.txt @ 18:b1e7b45fb3c8
Anmerkungen von Michi eingearbeitet
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Tue, 19 May 2015 07:30:07 +0200 |
| parents | 08f539a5445d |
| children | a62964d0cc54 |
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. Es gilt sowohl
79 fuer die Eingabe als auch fuer die Ausgabe.
81 Der typische Anwendungsfall fuer cut im Feldmodus ist die
82 Auswahl von Information aus der passwd-Datei. So 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 fuer die Optionen koennen bei cut uebrigens
93 mit Whitespace abgetrennt oder direkt angehaengt folgen.)
95 Dieser Feldmodus ist fuer einfache tabellarische Dateien,
96 wie eben die passwd, gut geeignet. Er kommt aber schnell an
97 seine Grenzen. Gerade der haeufige 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 also nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
101 werden. Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
102 stehende Trennzeichen fuehren 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 gewuenschte Verhalten
107 fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
108 man portabel bleiben will, verwendet man awk in diesen
109 Faellen.
111 Awk bietet noch eine weitere Funktion, die cut missen
112 laesst: 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. So gibt der Aufruf
115 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
116 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
117 der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
118 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
119 dabei immer gleich geordnet wie in der Eingabe. Um die Worte
120 der Manpage von Version 8 Unix wiederzugeben: ``In data base
121 parlance, it projects a relation.''
122 [ http://man.cat-v.org/unix_8th/1/cut
123 Cut fuehrt also die Datenbankoperation Projektion auf
124 Textdateien aus. Die Wikipedia erklaert das folgendermassen:
126 Die Projektion entspricht der Projektionsabbildung aus der
127 Mengenlehre und kann auch Attributbeschränkung genannt
128 werden. Sie extrahiert einzelne Attribute aus der
129 ursprünglichen Attributmenge und ist somit als eine Art
130 Selektion auf Spaltenebene zu verstehen, das heißt, die
131 Projektion blendet Spalten aus.
133 [ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
136 Geschichtliches
138 Cut erblickte 1982 mit dem Release von UNIX System III das
139 Licht der oeffentlichen Welt. Wenn man die Quellen von System
140 III durchforstet, findet man die Quellcodedatei cut.c mit dem
141 Zeitstempel 1980-04-11.
142 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
143 Das ist die aelteste Manifestation des Programms, die ich
144 aufstoebern konnte. Allerdings spricht die SCCS-ID im
145 Quellcode von Version 1.5. Es muss also noch eine
146 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
147 gefunden.
148 XXX mail an TUHS
150 Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester
151 Fund ein cut.c mit dem Dateimodifikationsdatum 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) tauchte cut nicht auf.
159 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
160 ein cut mit aus. Dieses cut war 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 Nun muss man wissen, dass POSIX.2 erst im September
168 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
169 Manpage und das Programm geschrieben worden waren. Das Programm
170 wurde folglich anhand von Arbeitsversionen des Standards
171 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
172 In der Funktion zum parsen der Feldauswahlliste findet sich
173 dieser Kommentar:
175 This parser is less restrictive than the Draft 9 POSIX spec.
176 POSIX doesn't allow lists that aren't in increasing order or
177 overlapping lists.
179 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits
180 ein:
182 The elements in list can be repeated, can overlap, and can
183 be specified in any order.
185 Auch listet Draft 11.2 alle drei Modi, waehrend in diesem
186 BSD cut nur die zwei alten implementiert sind. Es koennte also
187 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
188 Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
189 leider nicht moeglich, diese Vermutung zu pruefen. XXX
191 Die Versionsnummern und Aenderungsdaten der aelteren
192 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
193 damaligen Versionskontrollsystem in den Code eingefuegt wurden,
194 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
196 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
198 Copyright (C) 1997-2015 Free Software Foundation, Inc.
199 Copyright (C) 1984 David M. Ihnat
201 Der Code hat also recht alte Urspruenge. Wie aus weiteren
202 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
203 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
204 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
205 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
206 Copyright-Vermerk auftauchen, ist unklar.
208 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
209 aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
210 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
211 so war Unix doch schon ueber zehn Jahre alt, als cut das
212 erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht
213 zu Version 7 Unix, das die Ausgangsbasis aller modernen
214 Unix-Systeme darstellt. Die weit komplexeren Programme sed
215 und awk waren dort schon vertreten. Man muss sich also
216 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
217 schon zwei Programme gab, die die Funktion von cut abdecken
218 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
219 die damit verbundene Geschwindigkeit gegenueber dem damals
220 traegen awk. Diese schlanke Gestalt ist es auch, die der
221 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
222 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
223 standardisiert und ist heutzutage ueberall anzutreffen.
225 Die urspruengliche Variante (ohne -b) wurde schon 1985 in
226 der System V Interface Definition, einer wichtigen formalen
227 Beschreibung von UNIX System V, spezifiziert und tauchte
228 anschliessend in allen relevanten Standards auf. Mit POSIX.2
229 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
230 (mit -b) standardisiert.
231 XXX sicher?
234 Multibyte-Unterstuetzung
236 Nun sind der Bytemodus und die damit verbundene
237 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
238 1992 standardisiert, wie steht es aber mit deren Umsetzung?
239 Welche Versionen implementieren POSIX korrekt?
240 Die Situation ist dreiteilig: Es gibt historische
241 Implementierungen, die nur -c und -f kennen. Dann gibt es
242 Implementierungen die -b zwar kennen, es aber lediglich als Alias
243 fuer -c handhaben. Diese Implementierungen funktionieren mit
244 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
245 Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
246 wie -b (und -n wird ignoriert). Schliesslich gibt es noch
247 Implementierungen, die -b und -c tatsaechlich POSIX-konform
248 implementieren.
250 Historische Zwei-Modi-Implementierungen sind z.B. die von
251 System III, System V und die aller BSDs bis in die 90er.
253 Pseudo-Multibyte-Implementierungen bieten GNU und die
254 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
255 ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
256 Teilweise findet man erst nach genauerer Suche heraus, dass
257 -c und -n nicht wie erwartet funktionieren; teilweise machen es
258 sich die Systeme auch einfach, indem sie auf
259 Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
260 klar darlegen:
262 Since we don't support multi-byte characters, the -c and -b
263 options are equivalent, and the -n option is meaningless.
265 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
267 Tatsaechlich standardkonforme Implementierungen, die
268 Multibytes korrekt handhaben, bekommt man bei einem modernen
269 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
270 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
271 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
272 Warum die beiden anderen grossen BSDs diese Aenderung nicht
273 uebernommen haben, bleibt offen. Es scheint aber an der im
274 obigen Kommentar formulierten Grundausrichtung zu liegen.
276 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
277 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
278 entscheidend, ob das System selbst mit einem Multibyte-Encoding
279 arbeitet, denn tut es das nicht, dann entsprechen sich
280 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
281 herausfinden indem man sich das Locale anschaut, aber einfacher
282 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
283 auszugeben und zu schauen ob dieses in einem oder in mehreren
284 Bytes kodiert ist:
286 $ echo ä | od -c
287 0000000 303 244 \n
288 0000003
290 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
291 Zeilenumbruch fuegt echo(1) hinzu.)
293 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
294 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
295 bei Latin1 und wie sie bei UTF-8 aussieht.
297 $ echo ä | iconv -t latin1 | od -c
298 0000000 344 \n
299 0000002
301 $ echo ä | iconv -t utf8 | od -c
302 0000000 303 244 \n
303 0000003
305 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
306 wird recht sicher einer dieser beiden Ausgaben entsprechen.
308 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
309 dann sollte sich eine POSIX-konforme Implementierung folgendermassen
310 verhalten:
312 $ echo ä | cut -c 1 | od -c
313 0000000 303 244 \n
314 0000003
316 $ echo ä | cut -b 1 | od -c
317 0000000 303 \n
318 0000002
320 $ echo ä | cut -b 1 -n | od -c
321 0000000 \n
322 0000001
324 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
325 allen drei Faellen wie die mittlere: Es wird das erste Byte
326 ausgegeben.
329 Implementierungen
331 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
332 Implementierungen.
334 Fuer einen ersten Eindruck ist der Umfang des Quellcodes
335 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
336 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
337 bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
338 erfordert zwangslaeufig mehr Code, deshalb sind diese
339 Implementierungen tendenziell umfangreicher.
342 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie
343 -----------------------------------------------------------------
344 116 123 2966 System III 1980-04-11 (hist)
345 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist)
346 200 256 5715 4.3BSD-Reno 1990-06-25 (hist)
347 200 270 6545 NetBSD 1993-03-21 (hist)
348 218 290 6892 OpenBSD 2008-06-27 (pseudo)
349 224 296 6920 FreeBSD 1994-05-27 (hist)
350 232 306 7500 NetBSD 2014-02-03 (pseudo)
351 340 405 7423 Heirloom 2012-05-20 (POSIX)
352 382 586 14175 GNU coreutils 1992-11-08 (pseudo)
353 391 479 10961 FreeBSD 2012-11-24 (POSIX)
354 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
357 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
358 urspruenglichen Implementierungen, die sich nur minimal
359 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
360 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
361 die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
362 moderne GNU-Variante mit fast 600 SLOCs.
364 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
365 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
366 -l') erstreckt sich ueber eine Spanne von Faktor 1.06 bei den
367 aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Der groesste
368 Einflussfaktor darauf haben Leerzeilen, reine Kommentarzeilen und
369 die Groesse des Lizenzblocks am Dateianfang.
371 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
372 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
373 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
374 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
375 fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren
376 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
377 Ob man die Heirloom-Implementierung als besonders kryptisch
378 oder als besonders elegant bezeichnen will, das soll der
379 eigenen Einschaetzung des Lesers ueberlassen bleiben. Vor allem
380 der Vergleich mit einer GNU-Implementierung ist eindrucksvoll.
383 Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
384 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
385 verarbeitet, gibt es im Normalfall eine Funktion, die die
386 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
387 haben fast alle Implementierungen separate Funktionen fuer die
388 zwei bzw. drei Modi. Bei den POSIX-konformen Implementierungen
389 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
390 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
391 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
392 wird ausser den Fehlerausgaben alles in der main-Funktion
393 erledigt.
395 Cut-Implementierungen haben typischerweise zwei limitierende
396 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
397 Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt.
398 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
399 Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
400 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
401 Heirloom kann sowohl die Felderanzahl als auch die maximale
402 Zeilenlaenge beliebig gross werden; der Speicher dafuer wird
403 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
404 Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
405 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
406 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
407 gross genug sein sollte.
410 Beschreibungen
412 Interessant ist auch ein Vergleich der Kurzbeschreibungen von
413 cut, wie sie sich in der Titelzeile der Manpages oder manchmal
414 auch am Anfang der Quellcodedatei finden. Die folgende Liste
415 ist grob zeitlich geordnet und nach Abstammung gruppiert:
418 System III cut out selected fields of each line of a file
419 System III (src) cut and paste columns of a table (projection of a relation)
420 System V cut out selected fields of each line of a file
421 HP-UX cut out (extract) selected fields of each line of a file
423 4.3BSD-UWisc (src) cut and paste columns of a table (projection of a relation)
424 4.3BSD-Reno select portions of each line of a file
425 NetBSD select portions of each line of a file
426 OpenBSD 4.6 select portions of each line of a file
427 FreeBSD 1.0 select portions of each line of a file
428 FreeBSD 10.0 cut out selected portions of each line of a file
429 SunOS 4.1.3 remove selected fields from each line of a file
430 SunOS 5.5.1 cut out selected fields of each line of a file
432 Heirloom Tools cut out selected fields of each line of a file
433 Heirloom Tools (src) cut out fields of lines of files
435 GNU coreutils remove sections from each line of files
437 Minix select out columns of a file
439 Version 8 Unix rearrange columns of data
440 ``Unix Reader'' rearrange columns of text
442 POSIX cut out selected fields of each line of a file
445 Die mit ``(src)'' markierten Beschreibungen sind aus dem
446 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
447 die Beschreibung im Standard. Der ``Unix Reader'' ist ein
448 rueckblickendes Textdokument von Doug McIlroy, das das
449 Auftreten der Tools in der Geschichte des Research Unix zum
450 Thema hat.
451 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
452 Eigentlich sollte seine Beschreibung der in Version 8 Unix
453 entsprechen. Die Abweichung koennte sowohl ein
454 Uebertragungsfehler als auch eine nachtraegliche Korrektur
455 sein. Alle uebrigen Beschreibungen entstammen den Manpages.
457 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
458 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
459 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
461 Interessant ist, dass die GNU coreutils seit Anbeginn vom
462 Entfernen von Teilen der Eingabe sprechen, wohingegen die
463 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
464 Worte ``cut out'' sind vielleicht auch etwas zu
465 missverstaendlich. HP-UX hat sie deshalb praezisiert.
467 Auch beim Begriff, was selektiert wird, ist man sich
468 uneins. Die Einen reden von Feldern (POSIX), Andere von
469 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
470 (Research Unix). Ironischerweise leistet sich gerade Version
471 8 Unix, das eigentlich um eine sehr treffende Weltsicht
472 bemueht ist, mit ``rearrange columns of data'' die
473 unzutreffendste der Beschreibungen.
476 Autoreninfo
478 Markus Schnalke interessiert sich fuer die Hintergruende
479 von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses
480 Textes wurde er regelrecht zum Historiker.
483 Lizenz
485 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
486 veroeffentlicht werden)