docs/cut

annotate cut.txt @ 8:1dc4a9dca829

Zwischenstand
author markus schnalke <meillo@marmaro.de>
date Tue, 05 May 2015 09:04:00 +0200
parents 21ca59543b07
children e67bd0d48bd6
rev   line source
meillo@6 1 Das Werkzeugkaestle, #1
meillo@0 2
meillo@6 3 cut - cut out selected fields of each line of a file
meillo@6 4 ----------------------------------------------------
meillo@6 5 markus schnalke <meillo@marmaro.de>
meillo@6 6 2015-05
meillo@0 7
meillo@0 8
meillo@1 9 Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
meillo@8 10 In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
meillo@8 11 es. Es ist ein schoenes Anschauungsobjekt fuer's Shellscripting.
meillo@8 12 Hier soll ein wenig hinter die Fassade von cut geschaut werden.
meillo@0 13
meillo@0 14
meillo@4 15 Funktionsweise
meillo@4 16
meillo@8 17 Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten
meillo@8 18 erweitert wurden. Cut schneidet entweder bestimmte Zeichen aus
meillo@8 19 den Zeilen der Eingabe oder bestimmte, durch Trennzeichen
meillo@8 20 definierte, Felder.
meillo@0 21
meillo@8 22 Der Zeichenmodus ist geeignet um Festbreitenformaten zu
meillo@8 23 zerteilen. So kann man damit beispielsweise bestimmte
meillo@8 24 Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden. Hier
meillo@8 25 die Rechte des Besitzers:
meillo@0 26
meillo@4 27 $ ls -l foo | cut -c 2-4
meillo@4 28 rw-
meillo@0 29
meillo@4 30 Oder die Schreibrechte des Besitzers, der Gruppe und der
meillo@4 31 Welt:
meillo@0 32
meillo@4 33 $ ls -l | cut -c 3,6,9
meillo@4 34 ww-
meillo@0 35
meillo@4 36 Mit cut lassen sich aber auch Strings kuerzen.
meillo@0 37
meillo@6 38 $ echo "$long" | cut -c -20
meillo@0 39
meillo@8 40 Dieser Befehl gibt die ersten maximal 20 Zeichen von
meillo@8 41 `$long' aus. (Alternativ kann man hierfuer auch `printf
meillo@8 42 "%.20s\n" "$long"' verwenden.)
meillo@0 43
meillo@4 44 Geht es aber nicht um die Darstellung von Zeichen, sondern um
meillo@8 45 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
meillo@8 46 Frueher, als US-ASCII als Zeichensatz und -kodierung
meillo@4 47 noch omnipraesent war, wurde jedes Zeichen mit genau einem
meillo@4 48 Byte gespeichert. Somit selektierte `cut -c' gleichermassen
meillo@4 49 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
meillo@4 50 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
meillo@4 51 dieser Annahme loesen. In diesem Zug bekam cut mit
meillo@8 52 POSIX.2-1992 einen Bytemodus mit der Option `-b'. Will man
meillo@4 53 also nur die ersten maximal 500 Bytes vor dem
meillo@0 54 Newline-Zeichen stehen haben (und den Rest stillschweigend
meillo@0 55 ignorieren), dann macht man das mit:
meillo@0 56
meillo@6 57 $ cut -b -500
meillo@0 58
meillo@4 59 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese
meillo@8 60 Funktion ist insbesondere fuer POSIX wichtig, da man so
meillo@8 61 Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
meillo@4 62 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
meillo@0 63
meillo@0 64 Neben dem Zeichen- bzw. Byte-Modus bietet cut noch den
meillo@8 65 Feld-Modus, den man mit `-f' einleitet. Mit ihm
meillo@4 66 koennen Felder ausgewaehlt werden. Das Trennzeichen (per
meillo@4 67 Default der Tab) kann mit `-d' geaendert werden.
meillo@0 68
meillo@8 69 Der typische Anwendungsfall fuer cut im Feld-Modus ist die
meillo@8 70 Auswahl von Information aus der passwd-Datei. So z.B. der
meillo@8 71 Benutername, seine ID und das Homeverzeichnis:
meillo@0 72
meillo@6 73 $ cut -d: -f1,3,6 /etc/passwd
meillo@0 74
meillo@0 75 (Die Argumente fuer die Optionen koennen bei cut uebrigens
meillo@8 76 mit Whitespace abgetrennt oder direkt angehaengt folgen.)
meillo@0 77
meillo@0 78
meillo@4 79 Dieser Feld-Modus ist fuer einfache tabellarische Dateien,
meillo@4 80 wie eben die passwd, gut geeignet. Er kommt aber schnell an
meillo@0 81 seine Grenzen. Gerade der uebliche Fall, dass an Whitespace
meillo@0 82 in Felder geteilt werden soll, wird damit nicht abgedeckt.
meillo@0 83 Der Delimiter kann nur genau ein Zeichen sein. Es kann also
meillo@0 84 nicht sowohl an Leerzeichen als auch an Tabs getrennt werden.
meillo@0 85 Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
meillo@4 86 stehende Trennzeichen fuehren zu einem leeren Feld. Dieses
meillo@8 87 Verhalten widerspricht den Erwartungen, die man an die
meillo@8 88 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
meillo@8 89 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
meillo@8 90 haben Erweiterungen, die das gewuenschte Verhalten fuer
meillo@8 91 Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
meillo@8 92 man portabel bleiben will, hilft awk.
meillo@0 93
meillo@4 94 Awk bietet noch eine weitere Funktion, die cut missen
meillo@8 95 laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
meillo@8 96 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
meillo@8 97 Feld kann selbst mehrfach angegeben werden. So gibt der Aufruf
meillo@8 98 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
meillo@8 99 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
meillo@8 100 der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
meillo@8 101 Teil der Ergebnismenge sein. Die Felder der Ergebnismenge sind
meillo@8 102 dabei immer gleich geordnet wie sie es in der Eingabe waren.
meillo@8 103 Oder, um die Worte der Manpage in Version 8 Unix
meillo@8 104 wiederzugeben: ``In data base parlance, it projects a relation.''
meillo@8 105 Cut fuehrt also die Datenbankoperation Projektion auf
meillo@8 106 Textdateien aus. Die Wikipedia erklaert das in
meillo@8 107 verstaendlicherer Sprache:
meillo@7 108
meillo@7 109 Die Projektion entspricht der Projektionsabbildung aus der
meillo@7 110 Mengenlehre und kann auch Attributbeschränkung genannt
meillo@7 111 werden. Sie extrahiert einzelne Attribute aus der
meillo@7 112 ursprünglichen Attributmenge und ist somit als eine Art
meillo@7 113 Selektion auf Spaltenebene zu verstehen, das heißt, die
meillo@7 114 Projektion blendet Spalten aus.
meillo@7 115
meillo@8 116 [ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
meillo@8 117
meillo@7 118
meillo@7 119
meillo@7 120
meillo@0 121 Geschichtliches
meillo@0 122
meillo@4 123 Cut erblickte 1982 mit dem Release von UNIX System III das
meillo@4 124 Licht der oeffentlichen Welt. Wenn man die Quellen von System
meillo@4 125 III durchforstet, findet man die Quellcodedatei cut.c mit dem
meillo@4 126 Zeitstempel 1980-04-11.
meillo@1 127 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
meillo@4 128 Das ist die aelteste Manifestation des Programms, die ich
meillo@8 129 aufstoebern konnte. Allerdings spricht die sccsid im
meillo@8 130 Quellcode von Version 1.5. Es muss also noch eine
meillo@8 131 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
meillo@8 132 gefunden.
meillo@0 133
meillo@1 134 Aber werfen wir doch einen Blick auf die BSD-Linie: Dort ist mein
meillo@8 135 fruehester Fund ein cut.c mit dem Dateimodifikationsdatum
meillo@8 136 1986-11-07
meillo@8 137 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
meillo@8 138 als Teil der Spezialversion 4.3BSD-UWisc,
meillo@6 139 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
meillo@6 140 die im Januar 1987 veroeffentlicht wurde.
meillo@8 141 Die Implementierung unterscheidet sich nur minimal von der
meillo@8 142 in System III.
meillo@8 143 Im bekannteren 4.3BSD-Tahoe (1988) taucht cut nicht auf.
meillo@8 144 Das darauf folgende 4.3BSD-Reno (1990) liefert aber wieder
meillo@8 145 ein cut mit aus. Dieses cut ist ein von Adam S. Moskowitz und
meillo@8 146 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
meillo@8 147 aufgenommen wurde.
meillo@1 148 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
meillo@4 149 Seine Manpage
meillo@1 150 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
meillo@4 151 erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
meillo@4 152 Nun sollte man wissen, dass POSIX.2 erst im September
meillo@8 153 1992 veroeffentlicht wurde, also gut zwei Jahren *nachdem* die
meillo@8 154 Manpage und das Programm geschrieben wurden. Das Programm
meillo@8 155 wurde also anhand von Arbeitsversionen des Standards
meillo@4 156 implementiert. Zweieinhalb Jahre Arbeit war immerhin schon in
meillo@4 157 den Standardisierungsprozess geflossen; bis zur
meillo@8 158 Fertigstellung sollte es aber noch weitere zwei Jahre dauern.
meillo@0 159
meillo@1 160 Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut
meillo@1 161 aus Sicht des urspruenglichen Unix zu den juengeren Tools.
meillo@1 162 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
meillo@4 163 so war Unix doch schon ueber zehn Jahre alt, als cut das
meillo@4 164 erste Mal auftauchte. Insbesondere gehoerte cut noch nicht
meillo@4 165 zu Version 7 Unix, das die Ausgangsbasis aller modernen
meillo@4 166 Unix-Systeme darstellt. Die weit komplexeren Programme sed
meillo@4 167 und awk waren dort schon vertreten. Man muss sich also
meillo@4 168 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
meillo@8 169 schon zwei Programme gab, die die Aufgabe von cut abdeckten.
meillo@8 170 Ein Argument fuer cut war sicher seine Kompaktheit und
meillo@4 171 die damit verbundene Geschwindigkeit gegenueber dem damals
meillo@4 172 traegen awk. Diese schlanke Gestalt ist es auch, die der Unix
meillo@4 173 Philosopie entspricht: Mache eine Aufgabe und die richtig!
meillo@4 174 So bewaehrte sich cut. Es wurde in andere Unix Varianten
meillo@4 175 uebernommen, standardisiert und ist heutzutage ueberall
meillo@1 176 anzutreffen.
meillo@1 177
meillo@8 178 Die urspruengliche Variante (ohne -b) tauchte schon 1985 in
meillo@5 179 der System V Interface Definition, einer wichtigen formalen
meillo@5 180 Beschreibung von UNIX System V, und in allen relevanten
meillo@5 181 Standards seither auf. Mit POSIX.2 im Jahre 1992 wurde cut
meillo@5 182 zum ersten Mal in der heutigen Form (mit -b) standardisiert.
meillo@1 183
meillo@1 184
meillo@8 185
meillo@8 186 Multibyte-Behandlung
meillo@8 187
meillo@8 188 Nun sind der Bytemodus und die damit verbundene
meillo@8 189 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
meillo@8 190 1992 standardisiert, wie steht es aber mit deren Umsetzung?
meillo@8 191 Welche Versionen implementieren denn den POSIX korrekt?
meillo@8 192 Die Situation ist mehrschichtig. Es gibt traditionelle
meillo@8 193 Implementierungen, die nur -c und -f kennen. Dann gibt es
meillo@8 194 Implementierungen die zwar -b kennen, es aber nur als Alias
meillo@8 195 fuer -c handhaben. Diese Implementierungen funktionieren mit
meillo@8 196 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
meillo@8 197 Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
meillo@8 198 wie -b (und -n wird ignoriert). Schliesslich gibt es noch
meillo@8 199 Implementierungen, die -b und -c tatsaechlich POSIX-konform
meillo@8 200 implementieren.
meillo@8 201
meillo@8 202 Traditionelle Zwei-Modi-Implementierungen sind z.B. die von
meillo@8 203 System III, System V und die aller BSDs bis in die 90er.
meillo@8 204
meillo@8 205 Pseude-Multibyte-Implementierungen bieten GNU und die
meillo@8 206 modernen NetBSDs und OpenBSDs. Wie sehr dort der Schein von
meillo@8 207 POSIX-konformitaet gewahrt wird, ist unterschiedlich. Nicht
meillo@8 208 immer findet man klare Aussagen wie diese:
meillo@8 209
meillo@8 210 /* Since we don't support multi-byte characters, the -c and -b
meillo@8 211 options are equivalent, and the -n option is meaningless. */
meillo@8 212
meillo@8 213 [ XXX
meillo@8 214
meillo@8 215 Tatsaechlich standardkonforme Implementierungen, die
meillo@8 216 Multibytes korrekt handhaben, bekommt man bei einem modernen
meillo@8 217 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
meillo@8 218 (tjr) im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
meillo@8 219 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
meillo@8 220 Warum die beiden anderen grossen BSDs diese Aenderung nicht
meillo@8 221 uebernommen haben, bleibt offen. Es scheint aber an der im
meillo@8 222 obigen Kommentar formulierten Grundausrichtung zu liegen.
meillo@8 223
meillo@8 224 Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen
meillo@8 225 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
meillo@8 226 entscheidend, ob das System selbst mit einem Multibyte-Encoding
meillo@8 227 arbeitet, denn tut es das nicht, dann entsprechen sich Zeichen
meillo@8 228 und Bytes und die Frage eruebrigt sich. Man kann dazu nachschauen,
meillo@8 229 welches Locale eingestellt ist, aber einfacher ist es, ein
meillo@8 230 typisches Mehrbytezeichen, wie z.B. einen Umlaut, auszugeben
meillo@8 231 und zu schauen ob dieses in einem oder in mehreren Bytes
meillo@8 232 kodiert ist:
meillo@8 233
meillo@8 234 $ echo ä | od -c
meillo@8 235 0000000 303 244 \n
meillo@8 236 0000003
meillo@8 237
meillo@8 238 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
meillo@8 239 Zeilenumbruch fuegt echo(1) hinzu.)
meillo@8 240
meillo@8 241 Mit dem Programm iconv(1) kann man Test explizit in bestimmte
meillo@8 242 Kodierungen konvertieren. Hier Beispiele, wie das Ergebnis
meillo@8 243 bei Latin1 und wie es bei UTF-8 aussieht.
meillo@8 244
meillo@8 245 $ echo ä | iconv -t latin1 | od -c
meillo@8 246 0000000 344 \n
meillo@8 247 0000002
meillo@8 248
meillo@8 249 $ echo ä | iconv -t utf8 | od -c
meillo@8 250 0000000 303 244 \n
meillo@8 251 0000003
meillo@8 252
meillo@8 253 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
meillo@8 254 wird recht sicher einer dieser beiden Ausgaben entsprechen.
meillo@8 255
meillo@8 256 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
meillo@8 257 dann sollte sich eine POSIX-konforme Implementierung so verhalten:
meillo@8 258
meillo@8 259 $ echo aä | ./cut -c -2 | od -c
meillo@8 260 0000000 a 303 244 \n
meillo@8 261 0000004
meillo@8 262
meillo@8 263 $ echo aä | ./cut -b -2 | od -c
meillo@8 264 0000000 a 303 \n
meillo@8 265 0000003
meillo@8 266
meillo@8 267 $ echo aä | ./cut -b -2 -n | od -c
meillo@8 268 0000000 a \n
meillo@8 269 0000002
meillo@8 270
meillo@8 271 Bei einer Implementierung, die -b und -c gleich behandelt,
meillo@8 272 ist die Ausgabe in allen drei Faellen wie die mittlere: Es
meillo@8 273 werden die ersten beiden Bytes ausgegeben.
meillo@8 274
meillo@8 275
meillo@8 276
meillo@8 277 Implementierungen
meillo@8 278
meillo@8 279 Nun zum Blick auf den Code. Hier soll eine Auswahl an
meillo@8 280 Implementierungen etwas genauer betrachtet werden. Fuer einen
meillo@8 281 ersten Eindruck ist der Umfang des Quellcodes hilfreich.
meillo@8 282 Typischerweise steigt dieser ueber die Jahre an. Diese
meillo@8 283 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
meillo@8 284 bestaetigt werden.
meillo@8 285
meillo@8 286 Die Unterstuetzung des Byte-Modus (-b) erfordert zwangslaeufig
meillo@8 287 mehr Code, deshalb ist zu erwarten, dass diejenigen
meillo@8 288 Implementierungen, die ihn haben, umfangreicher sind.
meillo@8 289
meillo@8 290 Codevergleich
meillo@8 291
meillo@8 292 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie
meillo@8 293 -----------------------------------------------------------------
meillo@8 294 116 123 2966 System III 1980-04-11 (trad)
meillo@8 295 118 125 3038 4.3BSD-UWisc 1986-11-07 (trad)
meillo@8 296 200 256 5715 4.3BSD-Reno 1990-06-25 (trad)
meillo@8 297 200 270 6545 NetBSD 1993-03-21 (trad)
meillo@8 298 218 290 6892 OpenBSD 2008-06-27 (pseudo)
meillo@8 299 224 296 6920 FreeBSD 1994-05-27 (trad)
meillo@8 300 232 306 7500 NetBSD 2014-02-03 (pseudo)
meillo@8 301 340 405 7423 Heirloom 2012-05-20 (POSIX)
meillo@8 302 382 586 14175 GNU coreutils 1992-11-08 (pseudo)
meillo@8 303 391 479 10961 FreeBSD 2012-11-24 (POSIX)
meillo@8 304 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
meillo@8 305
meillo@8 306
meillo@8 307 $ awk -F' +' '{printf("%d\t%d (%.2f)\t%d (%.2f)\t%s\t%s\t%s\n",
meillo@8 308 $1, $2, $2/$1, $3, $3/$1, $4, $5, $6);}' <sloc
meillo@8 309 116 123 (1.06) 2966 (25.57) System III 1980-04-11 (trad)
meillo@8 310 118 125 (1.06) 3038 (25.75) 4.3BSD-UWisc 1986-11-07 (trad)
meillo@8 311 200 256 (1.28) 5715 (28.57) 4.3BSD-Reno 1990-06-25 (trad)
meillo@8 312 200 270 (1.35) 6545 (32.73) NetBSD 1993-03-21 (trad)
meillo@8 313 218 290 (1.33) 6892 (31.61) OpenBSD 2008-06-27 (pseudo)
meillo@8 314 224 296 (1.32) 6920 (30.89) FreeBSD 1994-05-27 (trad)
meillo@8 315 232 306 (1.32) 7500 (32.33) NetBSD 2014-02-03 (pseudo)
meillo@8 316 340 405 (1.19) 7423 (21.83) Heirloom 2012-05-20 (POSIX)
meillo@8 317 382 586 (1.53) 14175 (37.11) GNU coreutils 1992-11-08 (pseudo)
meillo@8 318 391 479 (1.23) 10961 (28.03) FreeBSD 2012-11-24 (POSIX)
meillo@8 319 588 830 (1.41) 23167 (39.40) GNU coreutils 2015-05-01 (pseudo)
meillo@8 320
meillo@8 321
meillo@8 322 Einige Auffaelligkeiten:
meillo@8 323
meillo@8 324 Das Kandidatenfeld teilt sich grob in vier Gruppen: Die zwei urspruenglichen
meillo@8 325 Implementierungen, die sich nur minimal unterscheiden, mit gut 100 SLOCs.
meillo@8 326 Dann die fuenf BSD-Versionen mit knapp ueber 200 SLOCs. Anschliessend die
meillo@8 327 zwei POSIX-konformen Programme und die alte GNU-Version mit 350-400
meillo@8 328 SLOCs. Und zum Abschluss die moderne GNU-Variante mit fast 600 SLOCs.
meillo@8 329
meillo@8 330 Die Abweichung von logischen Codezeilen (nach der Definition von
meillo@8 331 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei erstreckt
meillo@8 332 sich ueber einen Faktor von 1.06 bei den aeltesten Vertretern bis zu
meillo@8 333 Faktor 1.5 bei GNU.
meillo@8 334
meillo@8 335 Betrachtet man die Abweichungen zwischen den logischen Codezeilen und der
meillo@8 336 Dateigroesse, so pendelt das Teilnehmerfeld zwischen 25 und 30 Bytes je
meillo@8 337 Anweisung. Die Heirloom-Implementierung weicht nach unten ab, die
meillo@8 338 GNU-Implementierungen nach oben.
meillo@8 339
meillo@8 340
meillo@8 341
meillo@8 342 Das cut in System III von 1980 ist, wie man anhand der SCCS-ID erkennen
meillo@8 343 kann bereits in Version 1.5. Die Vorversionen konnte ich aber leider nicht
meillo@8 344 ermitteln.
meillo@8 345
meillo@8 346 Schaut man sich die SCCS-IDs in den BSD-Quellen an, dann findet man dort
meillo@8 347 Versionsnummern, die die Entwicklung dokumentieren:
meillo@8 348
meillo@8 349 4.3bsd-uwisc "@(#)cut.c 1.3";
meillo@8 350 4.3bsd-reno "@(#)cut.c 5.3 (Berkeley) 6/24/90";
meillo@8 351 netbsd "@(#)cut.c 5.4 (Berkeley) 10/30/90";
meillo@8 352 freebsd "@(#)cut.c 8.1 (Berkeley) 6/6/93";
meillo@8 353
meillo@8 354 Die neueren BSD-Versionen enthalten zwar weiterhin eine SCCS-ID, diese
meillo@8 355 ist aber bei Version "8.3 (Berkeley) 5/4/95" stehen geblieben. Danach
meillo@8 356 wurde scheinbar von SCCS auf CSV oder SVN gewechselt.
meillo@8 357
meillo@8 358 Bei GNU befindet sich folgender Copyright-Vermerk im Code:
meillo@8 359
meillo@8 360 Copyright (C) 1997-2015 Free Software Foundation, Inc.
meillo@8 361 Copyright (C) 1984 David M. Ihnat
meillo@8 362
meillo@8 363 Wie aus weiteren Kommentaren zu entnehmen ist, wurde der Code von zuerst
meillo@8 364 von David MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
meillo@8 365 hat den Code 1992 auch ins Versionkontrollsystem eingestellt. Weshalb
meillo@8 366 die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk auftauchen,
meillo@8 367 ist unklar.
meillo@8 368
meillo@8 369
meillo@8 370
meillo@8 371
meillo@2 372 Beschreibungen
meillo@1 373
meillo@2 374 Interessant ist ein Vergleich der Kurzbeschreibungen von cut,
meillo@3 375 wie sie sich in der Titelzeile von Manpages oder manchmal auch
meillo@5 376 am Anfang der Quellcodedatei finden.
meillo@2 377
meillo@5 378 Die folgende Liste ist grob nach Zeit geordnet und nach
meillo@5 379 Abstammung gruppiert:
meillo@3 380
meillo@3 381
meillo@2 382 System III cut out selected fields of each line of a file
meillo@3 383 System III (src) cut and paste columns of a table (projection of a relation)
meillo@2 384 System V cut out selected fields of each line of a file
meillo@2 385 HP-UX cut out (extract) selected fields of each line of a file
meillo@2 386
meillo@3 387 4.3BSD-UWisc (src) cut and paste columns of a table (projection of a relation)
meillo@2 388 4.3BSD-Reno select portions of each line of a file
meillo@2 389 NetBSD select portions of each line of a file
meillo@7 390 OpenBSD 4.6 select portions of each line of a file
meillo@2 391 FreeBSD 1.0 select portions of each line of a file
meillo@3 392 FreeBSD 7.0 cut out selected portions of each line of a file
meillo@2 393 SunOS 4.1.3 remove selected fields from each line of a file
meillo@2 394 SunOS 5.5.1 cut out selected fields of each line of a file
meillo@2 395
meillo@8 396 Heirloom Tools cut out selected fields of each line of a file
meillo@8 397
meillo@2 398 POSIX cut out selected fields of each line of a file
meillo@2 399
meillo@2 400 GNU coreutils remove sections from each line of files
meillo@2 401
meillo@2 402 Minix select out columns of a file
meillo@2 403
meillo@2 404 Version 8 Unix rearrange columns of data
meillo@2 405 ``Unix Reader'' rearrange columns of text
meillo@2 406
meillo@2 407
meillo@5 408 Die zwei mit ``(src)'' markierten Beschreibungen sind aus
meillo@5 409 dem Quellcode entnommen, und verdeutlichen den Codetransfer.
meillo@5 410 POSIX ist ein Set von Standards, keine Implementierung. Der
meillo@5 411 ``Unix Reader'' ist ein rueckblickendes Textdokument von
meillo@5 412 Doug McIlroy, das das Auftreten von Tools in der Geschichte
meillo@5 413 des Research Unix zum Thema hat. Alle uebrigen Beschreibungen
meillo@5 414 entstammen den Manpages.
meillo@5 415
meillo@5 416 Zumeist ist mit der Zeit die POSIX-Beschreibung uebernommen
meillo@5 417 worden, wie beispielsweise bei FreeBSD zu sehen.
meillo@5 418 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
meillo@5 419
meillo@7 420 Interessant ist, dass die GNU coreutils seit Anbeginn vom
meillo@5 421 Entfernen von Teilen der Eingabe sprechen, wohingegen die
meillo@5 422 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
meillo@5 423 Worte ``cut out'' sind vielleicht auch nicht klar genug.
meillo@5 424 HP-UX hat sie deshalb praezisiert.
meillo@5 425
meillo@5 426 Auch beim Begriff, was denn nun selektiert wird, ist man sich
meillo@5 427 uneins. Die einen reden von Feldern (POSIX), andere von
meillo@5 428 Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten
meillo@5 429 (Research Unix). Ironischerweise leistet sich gerade Version
meillo@5 430 8 Unix, das eigentlich um eine sehr treffende Weltsicht
meillo@5 431 bemueht ist, mit ``rearrange columns of data'' die
meillo@5 432 unzutreffendste der Beschreibungen.
meillo@5 433
meillo@5 434
meillo@2 435
meillo@6 436
meillo@6 437 Autoreninfo
meillo@6 438
meillo@6 439 Markus Schnalke interessiert sich fuer die Hintergruende
meillo@6 440 von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses
meillo@6 441 Textes wurde er regelrecht zum Historiker.
meillo@6 442
meillo@6 443
meillo@6 444 Lizenz
meillo@6 445 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
meillo@6 446 veroeffentlicht werden)