1.1 --- a/cut.txt	Tue May 05 09:04:00 2015 +0200
     1.2 +++ b/cut.txt	Tue May 05 19:21:00 2015 +0200
     1.3 @@ -8,21 +8,22 @@
     1.4  
     1.5  Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
     1.6  In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
     1.7 -es. Es ist ein schoenes Anschauungsobjekt fuer's Shellscripting.
     1.8 -Hier soll ein wenig hinter die Fassade von cut geschaut werden.
     1.9 +es, denn es ist ein schoenes, praktisches und anschauliches
    1.10 +Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
    1.11 +werden.
    1.12  
    1.13  
    1.14  Funktionsweise
    1.15  
    1.16  Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten
    1.17 -erweitert wurden. Cut schneidet entweder bestimmte Zeichen aus
    1.18 -den Zeilen der Eingabe oder bestimmte, durch Trennzeichen
    1.19 +erweitert wurden. Cut schneidet entweder gewuenschte Zeichen aus
    1.20 +den Zeilen der Eingabe oder gewuenschte, durch Trennzeichen
    1.21  definierte, Felder.
    1.22  
    1.23 -Der Zeichenmodus ist geeignet um Festbreitenformaten zu
    1.24 +Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
    1.25  zerteilen. So kann man damit beispielsweise bestimmte
    1.26 -Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden. Hier
    1.27 -die Rechte des Besitzers:
    1.28 +Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in
    1.29 +diesem Beispiel die Rechte des Besitzers:
    1.30  
    1.31  	$ ls -l foo | cut -c 2-4
    1.32  	rw-
    1.33 @@ -49,7 +50,7 @@
    1.34  sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
    1.35  Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
    1.36  dieser Annahme loesen. In diesem Zug bekam cut mit
    1.37 -POSIX.2-1992 einen Bytemodus mit der Option `-b'. Will man
    1.38 +POSIX.2-1992 einen Bytemodus (Option `-b'). Will man
    1.39  also nur die ersten maximal 500 Bytes vor dem
    1.40  Newline-Zeichen stehen haben (und den Rest stillschweigend
    1.41  ignorieren), dann macht man das mit:
    1.42 @@ -71,14 +72,18 @@
    1.43  Benutername, seine ID und das Homeverzeichnis:
    1.44  
    1.45  	$ cut -d: -f1,3,6 /etc/passwd
    1.46 +	root:0:/root
    1.47 +	bin:1:/bin
    1.48 +	daemon:2:/sbin
    1.49 +	mail:8:/var/spool/mail
    1.50 +	...
    1.51  
    1.52  (Die Argumente fuer die Optionen koennen bei cut uebrigens
    1.53  mit Whitespace abgetrennt oder direkt angehaengt folgen.)
    1.54  
    1.55 -
    1.56  Dieser Feld-Modus ist fuer einfache tabellarische Dateien,
    1.57  wie eben die passwd, gut geeignet. Er kommt aber schnell an
    1.58 -seine Grenzen. Gerade der uebliche Fall, dass an Whitespace
    1.59 +seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
    1.60  in Felder geteilt werden soll, wird damit nicht abgedeckt.
    1.61  Der Delimiter kann nur genau ein Zeichen sein. Es kann also
    1.62  nicht sowohl an Leerzeichen als auch an Tabs getrennt werden.
    1.63 @@ -87,9 +92,10 @@
    1.64  Verhalten widerspricht den Erwartungen, die man an die
    1.65  Verarbeitung einer Datei mit Whitespace-getrennten Feldern
    1.66  hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
    1.67 -haben Erweiterungen, die das gewuenschte Verhalten fuer
    1.68 +haben aber Erweiterungen, die das gewuenschte Verhalten fuer
    1.69  Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
    1.70 -man portabel bleiben will, hilft awk.
    1.71 +man portabel bleiben will, verwendet man awk in diesen
    1.72 +Faellen.
    1.73  
    1.74  Awk bietet noch eine weitere Funktion, die cut missen
    1.75  laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
    1.76 @@ -98,10 +104,11 @@
    1.77  von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
    1.78  in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
    1.79  der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
    1.80 -Teil der Ergebnismenge sein. Die Felder der Ergebnismenge sind
    1.81 -dabei immer gleich geordnet wie sie es in der Eingabe waren.
    1.82 -Oder, um die Worte der Manpage in Version 8 Unix
    1.83 -wiederzugeben: ``In data base parlance, it projects a relation.''
    1.84 +Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
    1.85 +dabei immer gleich geordnet wie in der Eingabe. Um die Worte
    1.86 +der Manpage XXX von Version 8 Unix wiederzugeben: ``In data base
    1.87 +parlance, it projects a relation.''
    1.88 +[ XXX
    1.89  Cut fuehrt also die Datenbankoperation Projektion auf
    1.90  Textdateien aus. Die Wikipedia erklaert das in
    1.91  verstaendlicherer Sprache:
    1.92 @@ -116,8 +123,6 @@
    1.93  [ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
    1.94  
    1.95  
    1.96 -
    1.97 -
    1.98  Geschichtliches
    1.99  
   1.100  Cut erblickte 1982 mit dem Release von UNIX System III das
   1.101 @@ -130,6 +135,7 @@
   1.102  Quellcode von Version 1.5. Es muss also noch eine
   1.103  Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
   1.104  gefunden.
   1.105 +XXX mail an TUHS
   1.106  
   1.107  Aber werfen wir doch einen Blick auf die BSD-Linie: Dort ist mein
   1.108  fruehester Fund ein cut.c mit dem Dateimodifikationsdatum
   1.109 @@ -149,6 +155,7 @@
   1.110  Seine Manpage
   1.111  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
   1.112  erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
   1.113 +XXX 2 oder 3 modi?
   1.114  Nun sollte man wissen, dass POSIX.2 erst im September
   1.115  1992 veroeffentlicht wurde, also gut zwei Jahren *nachdem* die
   1.116  Manpage und das Programm geschrieben wurden. Das Programm
   1.117 @@ -157,39 +164,42 @@
   1.118  den Standardisierungsprozess geflossen; bis zur
   1.119  Fertigstellung sollte es aber noch weitere zwei Jahre dauern.
   1.120  
   1.121 +Das cut der GNU Coreutils enthaelt einen Copyrightvermerk von
   1.122 +David M. Ihnat aus dem Jahr 1984.
   1.123 +
   1.124  Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut
   1.125  aus Sicht des urspruenglichen Unix zu den juengeren Tools.
   1.126  Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
   1.127  so war Unix doch schon ueber zehn Jahre alt, als cut das
   1.128 -erste Mal auftauchte. Insbesondere gehoerte cut noch nicht
   1.129 +erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht
   1.130  zu Version 7 Unix, das die Ausgangsbasis aller modernen
   1.131  Unix-Systeme darstellt. Die weit komplexeren Programme sed
   1.132  und awk waren dort schon vertreten. Man muss sich also
   1.133  fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
   1.134 -schon zwei Programme gab, die die Aufgabe von cut abdeckten.
   1.135 -Ein Argument fuer cut war sicher seine Kompaktheit und
   1.136 +schon zwei Programme gab, die die Funktion von cut abdecken
   1.137 +konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
   1.138  die damit verbundene Geschwindigkeit gegenueber dem damals
   1.139  traegen awk. Diese schlanke Gestalt ist es auch, die der Unix
   1.140  Philosopie entspricht: Mache eine Aufgabe und die richtig!
   1.141 -So bewaehrte sich cut. Es wurde in andere Unix Varianten
   1.142 -uebernommen, standardisiert und ist heutzutage ueberall
   1.143 -anzutreffen.
   1.144 +Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
   1.145 +standardisiert und ist heutzutage ueberall anzutreffen.
   1.146  
   1.147 -Die urspruengliche Variante (ohne -b) tauchte schon 1985 in
   1.148 +Die urspruengliche Variante (ohne -b) wurde schon 1985 in
   1.149  der System V Interface Definition, einer wichtigen formalen
   1.150 -Beschreibung von UNIX System V, und in allen relevanten
   1.151 -Standards seither auf. Mit POSIX.2 im Jahre 1992 wurde cut
   1.152 -zum ersten Mal in der heutigen Form (mit -b) standardisiert.
   1.153 +Beschreibung von UNIX System V, spezifiziert und tauchte
   1.154 +anschliessend in allen relevanten Standards auf. Mit POSIX.2
   1.155 +im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
   1.156 +(mit -b) standardisiert.
   1.157 +XXX sicher? s.o.
   1.158  
   1.159  
   1.160 -
   1.161 -Multibyte-Behandlung
   1.162 +Multibyte-Unterstuetzung
   1.163  
   1.164  Nun sind der Bytemodus und die damit verbundene
   1.165  Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
   1.166  1992 standardisiert, wie steht es aber mit deren Umsetzung?
   1.167  Welche Versionen implementieren denn den POSIX korrekt?
   1.168 -Die Situation ist mehrschichtig. Es gibt traditionelle
   1.169 +Die Situation ist dreiteilig: Es gibt traditionelle
   1.170  Implementierungen, die nur -c und -f kennen. Dann gibt es
   1.171  Implementierungen die zwar -b kennen, es aber nur als Alias
   1.172  fuer -c handhaben. Diese Implementierungen funktionieren mit
   1.173 @@ -203,8 +213,8 @@
   1.174  System III, System V und die aller BSDs bis in die 90er.
   1.175  
   1.176  Pseude-Multibyte-Implementierungen bieten GNU und die
   1.177 -modernen NetBSDs und OpenBSDs. Wie sehr dort der Schein von
   1.178 -POSIX-konformitaet gewahrt wird, ist unterschiedlich. Nicht
   1.179 +modernen NetBSDs und OpenBSDs. Wie sehr dort ein Schein von
   1.180 +POSIX-Konformitaet gewahrt wird, ist unterschiedlich. Nicht
   1.181  immer findet man klare Aussagen wie diese:
   1.182  
   1.183  	/* Since we don't support multi-byte characters, the -c and -b 
   1.184 @@ -215,7 +225,7 @@
   1.185  Tatsaechlich standardkonforme Implementierungen, die
   1.186  Multibytes korrekt handhaben, bekommt man bei einem modernen
   1.187  FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
   1.188 -(tjr) im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
   1.189 +im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
   1.190  [ https://svnweb.freebsd.org/base?view=revision&revision=131194
   1.191  Warum die beiden anderen grossen BSDs diese Aenderung nicht
   1.192  uebernommen haben, bleibt offen. Es scheint aber an der im
   1.193 @@ -224,12 +234,12 @@
   1.194  Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen
   1.195  Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
   1.196  entscheidend, ob das System selbst mit einem Multibyte-Encoding
   1.197 -arbeitet, denn tut es das nicht, dann entsprechen sich Zeichen
   1.198 -und Bytes und die Frage eruebrigt sich. Man kann dazu nachschauen,
   1.199 -welches Locale eingestellt ist, aber einfacher ist es, ein
   1.200 -typisches Mehrbytezeichen, wie z.B. einen Umlaut, auszugeben
   1.201 -und zu schauen ob dieses in einem oder in mehreren Bytes
   1.202 -kodiert ist:
   1.203 +arbeitet, denn tut es das nicht, dann entsprechen sich naemlich
   1.204 +Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
   1.205 +herausfinden indem man sich das Locale anschaut, aber einfacher
   1.206 +ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
   1.207 +auszugeben und zu schauen ob dieses in einem oder in mehreren
   1.208 +Bytes kodiert ist:
   1.209  
   1.210  	$ echo ä | od -c
   1.211  	0000000 303 244  \n
   1.212 @@ -238,7 +248,7 @@
   1.213  In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
   1.214  Zeilenumbruch fuegt echo(1) hinzu.)
   1.215  
   1.216 -Mit dem Programm iconv(1) kann man Test explizit in bestimmte
   1.217 +Mit dem Programm iconv(1) kann man Text explizit in bestimmte
   1.218  Kodierungen konvertieren. Hier Beispiele, wie das Ergebnis
   1.219  bei Latin1 und wie es bei UTF-8 aussieht.
   1.220  
   1.221 @@ -273,110 +283,95 @@
   1.222  werden die ersten beiden Bytes ausgegeben.
   1.223  
   1.224  
   1.225 -
   1.226  Implementierungen
   1.227  
   1.228 -Nun zum Blick auf den Code. Hier soll eine Auswahl an
   1.229 -Implementierungen etwas genauer betrachtet werden. Fuer einen
   1.230 -ersten Eindruck ist der Umfang des Quellcodes hilfreich.
   1.231 -Typischerweise steigt dieser ueber die Jahre an. Diese
   1.232 +Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
   1.233 +Implementierungen.
   1.234 +
   1.235 +Fuer einen ersten Eindruck ist der Umfang des Quellcodes
   1.236 +hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
   1.237  Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
   1.238 -bestaetigt werden.
   1.239 +bestaetigt werden. Die Unterstuetzung des Byte-Modus (-b)
   1.240 +erfordert zwangslaeufig mehr Code, deshalb sind die
   1.241 +POSIX-konformen Implementierungen tendenziell umfangreicher.
   1.242  
   1.243 -Die Unterstuetzung des Byte-Modus (-b) erfordert zwangslaeufig
   1.244 -mehr Code, deshalb ist zu erwarten, dass diejenigen
   1.245 -Implementierungen, die ihn haben, umfangreicher sind.
   1.246  
   1.247 -Codevergleich
   1.248 +	SLOC	Zeilen	Bytes	Gehoert zu  	Dateidatum	Kategorie
   1.249 +	-----------------------------------------------------------------
   1.250 +	116	123	 2966	System III	1980-04-11	(trad)
   1.251 +	118	125	 3038	4.3BSD-UWisc	1986-11-07	(trad)
   1.252 +	200	256	 5715	4.3BSD-Reno	1990-06-25	(trad)
   1.253 +	200	270	 6545	NetBSD	 	1993-03-21	(trad)
   1.254 +	218	290	 6892	OpenBSD		2008-06-27	(pseudo)
   1.255 +	224	296	 6920	FreeBSD		1994-05-27	(trad)
   1.256 +	232	306	 7500	NetBSD 		2014-02-03	(pseudo)
   1.257 +	340	405	 7423	Heirloom	2012-05-20	(POSIX)
   1.258 +	382	586	14175	GNU coreutils	1992-11-08	(pseudo)
   1.259 +	391	479	10961	FreeBSD		2012-11-24	(POSIX)
   1.260 +	588	830	23167	GNU coreutils	2015-05-01	(pseudo)
   1.261 +XXX verlinken
   1.262  
   1.263 -SLOC	Zeilen	Bytes	Gehoert zu  	Dateidatum	Kategorie
   1.264 ------------------------------------------------------------------
   1.265 -116	123	 2966	System III	1980-04-11	(trad)
   1.266 -118	125	 3038	4.3BSD-UWisc	1986-11-07	(trad)
   1.267 -200	256	 5715	4.3BSD-Reno	1990-06-25	(trad)
   1.268 -200	270	 6545	NetBSD	 	1993-03-21	(trad)
   1.269 -218	290	 6892	OpenBSD		2008-06-27	(pseudo)
   1.270 -224	296	 6920	FreeBSD		1994-05-27	(trad)
   1.271 -232	306	 7500	NetBSD 		2014-02-03	(pseudo)
   1.272 -340	405	 7423	Heirloom	2012-05-20	(POSIX)
   1.273 -382	586	14175	GNU coreutils	1992-11-08	(pseudo)
   1.274 -391	479	10961	FreeBSD		2012-11-24	(POSIX)
   1.275 -588	830	23167	GNU coreutils	2015-05-01	(pseudo)
   1.276  
   1.277 +Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
   1.278 +urspruenglichen Implementierungen, die sich nur minimal
   1.279 +unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
   1.280 +gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
   1.281 +die alte GNU-Version mit 340-390 SLOCs. Und (4) die moderne
   1.282 +GNU-Variante mit fast 600 SLOCs.
   1.283  
   1.284 -$ awk -F'  +' '{printf("%d\t%d (%.2f)\t%d (%.2f)\t%s\t%s\t%s\n",
   1.285 -		$1, $2, $2/$1, $3, $3/$1, $4, $5, $6);}' <sloc                
   1.286 -116     123 (1.06)      2966 (25.57)    System III      1980-04-11   (trad)
   1.287 -118     125 (1.06)      3038 (25.75)    4.3BSD-UWisc    1986-11-07   (trad)
   1.288 -200     256 (1.28)      5715 (28.57)    4.3BSD-Reno     1990-06-25   (trad)
   1.289 -200     270 (1.35)      6545 (32.73)    NetBSD          1993-03-21   (trad)
   1.290 -218     290 (1.33)      6892 (31.61)    OpenBSD         2008-06-27   (pseudo)
   1.291 -224     296 (1.32)      6920 (30.89)    FreeBSD         1994-05-27   (trad)
   1.292 -232     306 (1.32)      7500 (32.33)    NetBSD          2014-02-03   (pseudo)
   1.293 -340     405 (1.19)      7423 (21.83)    Heirloom        2012-05-20   (POSIX)
   1.294 -382     586 (1.53)      14175 (37.11)   GNU coreutils   1992-11-08   (pseudo)
   1.295 -391     479 (1.23)      10961 (28.03)   FreeBSD         2012-11-24   (POSIX)
   1.296 -588     830 (1.41)      23167 (39.40)   GNU coreutils   2015-05-01   (pseudo)
   1.297 +Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
   1.298 +SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
   1.299 +-l') erstreckt sich ueber einen Faktor von 1.06 bei den aeltesten
   1.300 +Vertretern bis zu Faktor 1.5 bei GNU. Der groesste
   1.301 +Einflussfaktor darauf sind Leerzeilen, reine Kommentarzeilen und
   1.302 +die Groesse des Lizenzblocks am Dateianfang. 
   1.303  
   1.304 +Betrachtet man die Abweichungen zwischen den logischen Codezeilen
   1.305 +und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
   1.306 +zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
   1.307 +weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
   1.308 +fast 40 nach oben. Dies liegt bei GNU hauptsaechlich am
   1.309 +Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
   1.310 +Ob man die Heirloom-Implementierung als besonders kryptisch
   1.311 +oder als besonders elegant bezeichnen will, das soll der
   1.312 +eigenen Einschaetzung des Lesers ueberlassen bleiben.
   1.313  
   1.314 -Einige Auffaelligkeiten:
   1.315  
   1.316 -Das Kandidatenfeld teilt sich grob in vier Gruppen: Die zwei urspruenglichen
   1.317 -Implementierungen, die sich nur minimal unterscheiden, mit gut 100 SLOCs.
   1.318 -Dann die fuenf BSD-Versionen mit knapp ueber 200 SLOCs. Anschliessend die
   1.319 -zwei POSIX-konformen Programme und die alte GNU-Version mit 350-400
   1.320 -SLOCs. Und zum Abschluss die moderne GNU-Variante mit fast 600 SLOCs.
   1.321 +Schaut man sich die SCCS-IDs (die vom damaligen
   1.322 +Versionskontrollsystem eingefuegt wurden) in den BSD-Quellen an,
   1.323 +dann findet man dort Versionsnummern, die die Entwicklung
   1.324 +dokumentieren:
   1.325  
   1.326 -Die Abweichung von logischen Codezeilen (nach der Definition von
   1.327 -SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei erstreckt 
   1.328 -sich ueber einen Faktor von 1.06 bei den aeltesten Vertretern bis zu
   1.329 -Faktor 1.5 bei GNU.
   1.330 -
   1.331 -Betrachtet man die Abweichungen zwischen den logischen Codezeilen und der
   1.332 -Dateigroesse, so pendelt das Teilnehmerfeld zwischen 25 und 30 Bytes je
   1.333 -Anweisung. Die Heirloom-Implementierung weicht nach unten ab, die
   1.334 -GNU-Implementierungen nach oben.
   1.335 -
   1.336 -
   1.337 -
   1.338 -Das cut in System III von 1980 ist, wie man anhand der SCCS-ID erkennen
   1.339 -kann bereits in Version 1.5. Die Vorversionen konnte ich aber leider nicht
   1.340 -ermitteln.
   1.341 -
   1.342 -Schaut man sich die SCCS-IDs in den BSD-Quellen an, dann findet man dort
   1.343 -Versionsnummern, die die Entwicklung dokumentieren:
   1.344 -
   1.345 -4.3bsd-uwisc	"@(#)cut.c      1.3";
   1.346 -4.3bsd-reno	"@(#)cut.c      5.3 (Berkeley) 6/24/90";
   1.347 -netbsd		"@(#)cut.c      5.4 (Berkeley) 10/30/90";
   1.348 -freebsd		"@(#)cut.c      8.1 (Berkeley) 6/6/93";
   1.349 +	4.3bsd-uwisc	"@(#)cut.c      1.3";
   1.350 +	4.3bsd-reno	"@(#)cut.c      5.3 (Berkeley) 6/24/90";
   1.351 +	netbsd		"@(#)cut.c      5.4 (Berkeley) 10/30/90";
   1.352 +	freebsd		"@(#)cut.c      8.1 (Berkeley) 6/6/93";
   1.353  
   1.354  Die neueren BSD-Versionen enthalten zwar weiterhin eine SCCS-ID, diese
   1.355  ist aber bei Version "8.3 (Berkeley) 5/4/95" stehen geblieben. Danach
   1.356 -wurde scheinbar von SCCS auf CSV oder SVN gewechselt.
   1.357 +wurde scheinbar von SCCS auf ein anderes
   1.358 +Versionskontrollsystem gewechselt.
   1.359 +XXX
   1.360  
   1.361  Bei GNU befindet sich folgender Copyright-Vermerk im Code:
   1.362  
   1.363 -   Copyright (C) 1997-2015 Free Software Foundation, Inc.
   1.364 -   Copyright (C) 1984 David M. Ihnat
   1.365 +	Copyright (C) 1997-2015 Free Software Foundation, Inc.
   1.366 +	Copyright (C) 1984 David M. Ihnat
   1.367  
   1.368 -Wie aus weiteren Kommentaren zu entnehmen ist, wurde der Code von zuerst
   1.369 -von David MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
   1.370 -hat den Code 1992 auch ins Versionkontrollsystem eingestellt. Weshalb
   1.371 -die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk auftauchen,
   1.372 -ist unklar.
   1.373 -
   1.374 -
   1.375 +Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren
   1.376 +Kommentaren zu entnehmen ist, wurde der Code zuerst von David
   1.377 +MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
   1.378 +hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
   1.379 +Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk
   1.380 +auftauchen, ist unklar.
   1.381  
   1.382  
   1.383  Beschreibungen
   1.384  
   1.385 -Interessant ist ein Vergleich der Kurzbeschreibungen von cut,
   1.386 -wie sie sich in der Titelzeile von Manpages oder manchmal auch
   1.387 -am Anfang der Quellcodedatei finden.
   1.388 -
   1.389 -Die folgende Liste ist grob nach Zeit geordnet und nach
   1.390 -Abstammung gruppiert:
   1.391 +Interessant ist auch ein Vergleich der Kurzbeschreibungen von
   1.392 +cut, wie sie sich in der Titelzeile von Manpages oder manchmal
   1.393 +auch am Anfang der Quellcodedatei finden. Die folgende Liste
   1.394 +ist grob zeitlich geordnet und nach Abstammung gruppiert:
   1.395  
   1.396  
   1.397  System III	cut out selected fields of each line of a file
   1.398 @@ -392,10 +387,10 @@
   1.399  FreeBSD 7.0	cut out selected portions of each line of a file
   1.400  SunOS 4.1.3	remove selected fields from each line of a file
   1.401  SunOS 5.5.1	cut out selected fields of each line of a file
   1.402 +XXX FreeBSD 10
   1.403  
   1.404  Heirloom Tools	cut out selected fields of each line of a file
   1.405 -
   1.406 -POSIX		cut out selected fields of each line of a file
   1.407 +Heirloom Tools (src)	cut out fields of lines of files
   1.408  
   1.409  GNU coreutils	remove sections from each line of files
   1.410  
   1.411 @@ -404,24 +399,32 @@
   1.412  Version 8 Unix	rearrange columns of data
   1.413  ``Unix Reader''	rearrange columns of text
   1.414  
   1.415 +POSIX		cut out selected fields of each line of a file
   1.416  
   1.417 -Die zwei mit ``(src)'' markierten Beschreibungen sind aus
   1.418 -dem Quellcode entnommen, und verdeutlichen den Codetransfer.
   1.419 -POSIX ist ein Set von Standards, keine Implementierung. Der
   1.420 -``Unix Reader'' ist ein rueckblickendes Textdokument von
   1.421 +
   1.422 +Die mit ``(src)'' markierten Beschreibungen sind aus dem
   1.423 +jeweiligen Quellcode entnommen.
   1.424 +Der POSIX-Eintrag enthaelt die Beschreibung des Standards.
   1.425 +Der ``Unix Reader'' ist ein rueckblickendes Textdokument von
   1.426  Doug McIlroy, das das Auftreten von Tools in der Geschichte
   1.427 -des Research Unix zum Thema hat. Alle uebrigen Beschreibungen
   1.428 -entstammen den Manpages.
   1.429 +des Research Unix zum Thema hat.
   1.430 +[ XXX
   1.431 +Eigentlich sollte seine
   1.432 +Beschreibung der in Version 8 Unix entsprechen. Die
   1.433 +Abweichung koennte sowohl ein Uebertragungsfehler als auch
   1.434 +eine nachtraegliche Korrektur sein.
   1.435 +Alle uebrigen Beschreibungen entstammen den Manpages.
   1.436  
   1.437 -Zumeist ist mit der Zeit die POSIX-Beschreibung uebernommen
   1.438 +Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
   1.439  worden, wie beispielsweise bei FreeBSD zu sehen.
   1.440  [ https://svnweb.freebsd.org/base?view=revision&revision=167101
   1.441 +XXX fixme!
   1.442  
   1.443  Interessant ist, dass die GNU coreutils seit Anbeginn vom
   1.444  Entfernen von Teilen der Eingabe sprechen, wohingegen die
   1.445  Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
   1.446 -Worte ``cut out'' sind vielleicht auch nicht klar genug.
   1.447 -HP-UX hat sie deshalb praezisiert.
   1.448 +Worte ``cut out'' sind vielleicht auch etwas
   1.449 +missverstaendlich. HP-UX hat sie deshalb praezisiert.
   1.450  
   1.451  Auch beim Begriff, was denn nun selektiert wird, ist man sich
   1.452  uneins. Die einen reden von Feldern (POSIX), andere von
   1.453 @@ -432,8 +435,6 @@
   1.454  unzutreffendste der Beschreibungen.
   1.455  
   1.456  
   1.457 -
   1.458 -
   1.459  Autoreninfo
   1.460  
   1.461  Markus Schnalke interessiert sich fuer die Hintergruende