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