--- a/cut.txt	Tue May 12 22:49:21 2015 +0200
+++ b/cut.txt	Wed May 13 07:18:16 2015 +0200
@@ -47,8 +47,8 @@
 
 Geht es aber nicht um die Darstellung von Zeichen, sondern um
 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
-Frueher, als US-ASCII als Zeichensatz und -kodierung
-noch omnipraesent war, wurde jedes Zeichen mit genau einem
+Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung
+war, wurde jedes Zeichen mit genau einem
 Byte gespeichert. Somit selektierte `cut -c' gleichermassen
 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
@@ -65,45 +65,45 @@
 Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
 
-Auch wenn der Bytemodus neu eingefuehrt wurde, so sollte er
-sich doch nur so verhalten wie der alte Zeichenmodus normalerweise
-implementiert war. Beim Zeichenmodus aber wurde durch POSIX.2
-eine andere Implementierungsweise gefordert. Das Problem war
-also nicht, den neuen Bytemodus zu implementieren, sondern
+Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte
+er sich doch nur so verhalten wie der alte Zeichenmodus
+normalerweise schon implementiert war. Beim Zeichenmodus aber
+wurde eine neue Implementierungsweise gefordert. Das Problem
+war also nicht, den neuen Bytemodus zu implementieren, sondern
 den Zeichenmodus neu zu implementieren.
 
-Neben dem Zeichen- und Byte-Modus bietet cut noch den
-Feld-Modus, den man mit `-f' einleitet. Mit ihm
+Neben dem Zeichen- und Bytemodus bietet cut noch den
+Feldmodus, den man mit `-f' einleitet. Mit ihm
 koennen Felder ausgewaehlt werden. Das Trennzeichen (per
 Default der Tab) kann mit `-d' geaendert werden.
 
-Der typische Anwendungsfall fuer cut im Feld-Modus ist die
+Der typische Anwendungsfall fuer cut im Feldmodus ist die
 Auswahl von Information aus der passwd-Datei. So z.B. der
-Benutzername, seine ID und das Homeverzeichnis:
+Benutzername und seine ID:
 
-	$ cut -d: -f1,3,6 /etc/passwd
-	root:0:/root
-	bin:1:/bin
-	daemon:2:/sbin
-	mail:8:/var/spool/mail
+	$ cut -d: -f1,3 /etc/passwd
+	root:0
+	bin:1
+	daemon:2
+	mail:8
 	...
 
 (Die Argumente fuer die Optionen koennen bei cut uebrigens
 mit Whitespace abgetrennt oder direkt angehaengt folgen.)
 
-Dieser Feld-Modus ist fuer einfache tabellarische Dateien,
+Dieser Feldmodus ist fuer einfache tabellarische Dateien,
 wie eben die passwd, gut geeignet. Er kommt aber schnell an
 seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
 in Felder geteilt werden soll, wird damit nicht abgedeckt.
-Der Delimiter kann nur genau ein Zeichen sein. Es kann also
-nicht sowohl an Leerzeichen als auch an Tabs getrennt werden.
-Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
+Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
+also nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
+werden. Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
 stehende Trennzeichen fuehren zu einem leeren Feld. Dieses
 Verhalten widerspricht den Erwartungen, die man an die
 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
-haben aber Erweiterungen, die das gewuenschte Verhalten fuer
-Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
+haben deshalb Erweiterungen, die das gewuenschte Verhalten
+fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
 man portabel bleiben will, verwendet man awk in diesen
 Faellen.
 
@@ -140,34 +140,32 @@
 Zeitstempel 1980-04-11.
 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
 Das ist die aelteste Manifestation des Programms, die ich
-aufstoebern konnte. Allerdings spricht die sccsid im
+aufstoebern konnte. Allerdings spricht die SCCS-ID im
 Quellcode von Version 1.5. Es muss also noch eine
 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
 gefunden.
 XXX mail an TUHS
 
-Nun ein Blick auf die BSD-Linie: Dort ist mein
-fruehester Fund ein cut.c mit dem Dateimodifikationsdatum
-1986-11-07
+Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester
+Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
 als Teil der Spezialversion 4.3BSD-UWisc,
 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
 die im Januar 1987 veroeffentlicht wurde.
 Die Implementierung unterscheidet sich nur minimal von der
 in System III.
-Im bekannteren 4.3BSD-Tahoe (1988) taucht cut nicht auf.
-Das darauf folgende 4.3BSD-Reno (1990) liefert aber wieder
-ein cut mit aus. Dieses cut ist ein von Adam S. Moskowitz und
+Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
+Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
+ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
 aufgenommen wurde.
 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
 Seine Manpage
 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
 erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
-XXX 2 oder 3 modi? Draft 9: 2 modi?  Draft 11.2 hat 3 modi!
-Nun sollte man wissen, dass POSIX.2 erst im September
+Nun muss man wissen, dass POSIX.2 erst im September
 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
-Manpage und das Programm geschrieben wurden. Das Programm
+Manpage und das Programm geschrieben worden waren. Das Programm
 wurde folglich anhand von Arbeitsversionen des Standards
 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
 In der Funktion zum parsen der Feldauswahlliste findet sich
@@ -183,9 +181,15 @@
 	The elements in list can be repeated, can overlap, and can
 	be specified in any order.
 
-Die Versionsnummern und Aenderungsdatums der aelteren
-BSD-Implementierungen kann man aus den SCCS-IDs (die vom
-damaligen Versionskontrollsystem in den Code eingefuegt wurden)
+Auch listet Draft 11.2 alle drei Modi, waehrend in diesem
+BSD cut nur die zwei alten implementiert sind. Es koennte also
+sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
+Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
+leider nicht moeglich, diese Vermutung zu pruefen. XXX
+
+Die Versionsnummern und Aenderungsdaten der aelteren
+BSD-Implementierungen kann man aus den SCCS-IDs, die vom
+damaligen Versionskontrollsystem in den Code eingefuegt wurden,
 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
 
 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
@@ -193,12 +197,12 @@
 	Copyright (C) 1997-2015 Free Software Foundation, Inc.
 	Copyright (C) 1984 David M. Ihnat
 
-Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren
-Kommentaren zu entnehmen ist, wurde der Code zuerst von David
+Der Code hat also recht alte Urspruenge. Wie aus weiteren
+Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
-Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk
-auftauchen, ist unklar.
+Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
+Copyright-Vermerk auftauchen, ist unklar.
 
 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
 aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
@@ -212,8 +216,8 @@
 schon zwei Programme gab, die die Funktion von cut abdecken
 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
 die damit verbundene Geschwindigkeit gegenueber dem damals
-traegen awk. Diese schlanke Gestalt ist es auch, die der Unix
-Philosopie entspricht: Mache eine Aufgabe und die richtig!
+traegen awk. Diese schlanke Gestalt ist es auch, die der
+Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
 standardisiert und ist heutzutage ueberall anzutreffen.
 
@@ -232,27 +236,27 @@
 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
 1992 standardisiert, wie steht es aber mit deren Umsetzung?
 Welche Versionen implementieren POSIX korrekt?
-Die Situation ist dreiteilig: Es gibt traditionelle
+Die Situation ist dreiteilig: Es gibt historische
 Implementierungen, die nur -c und -f kennen. Dann gibt es
 Implementierungen die -b zwar kennen, es aber lediglich als Alias
 fuer -c handhaben. Diese Implementierungen funktionieren mit
 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
-Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
+Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
 wie -b (und -n wird ignoriert). Schliesslich gibt es noch
 Implementierungen, die -b und -c tatsaechlich POSIX-konform
 implementieren.
 
-Traditionelle Zwei-Modi-Implementierungen sind z.B. die von
+Historische Zwei-Modi-Implementierungen sind z.B. die von
 System III, System V und die aller BSDs bis in die 90er.
 
 Pseudo-Multibyte-Implementierungen bieten GNU und die
-modernen NetBSDs und OpenBSDs. Man darf sich durchaus fragen,
+modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
 ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
 Teilweise findet man erst nach genauerer Suche heraus, dass
 -c und -n nicht wie erwartet funktionieren; teilweise machen es
-sich die System auch einfach, indem sie auf
-Singlebyte-Zeichenkodierungen beharren, das aber dafuer klar
-darlegen:
+sich die Systeme auch einfach, indem sie auf
+Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
+klar darlegen:
 
 	Since we don't support multi-byte characters, the -c and -b
 	options are equivalent, and the -n option is meaningless.
@@ -268,10 +272,10 @@
 uebernommen haben, bleibt offen. Es scheint aber an der im
 obigen Kommentar formulierten Grundausrichtung zu liegen.
 
-Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen
+Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
 entscheidend, ob das System selbst mit einem Multibyte-Encoding
-arbeitet, denn tut es das nicht, dann entsprechen sich naemlich
+arbeitet, denn tut es das nicht, dann entsprechen sich
 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
 herausfinden indem man sich das Locale anschaut, aber einfacher
 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
@@ -301,7 +305,8 @@
 wird recht sicher einer dieser beiden Ausgaben entsprechen.
 
 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
-dann sollte sich eine POSIX-konforme Implementierung so verhalten:
+dann sollte sich eine POSIX-konforme Implementierung folgendermassen
+verhalten:
 
 	$ echo ä | ./cut -c 1 | od -c
 	0000000 303 244  \n
@@ -328,19 +333,19 @@
 Fuer einen ersten Eindruck ist der Umfang des Quellcodes
 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
-bestaetigt werden. Die Unterstuetzung des Byte-Modus (-b)
-erfordert zwangslaeufig mehr Code, deshalb sind die
-POSIX-konformen Implementierungen tendenziell umfangreicher.
+bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
+erfordert zwangslaeufig mehr Code, deshalb sind diese
+Implementierungen tendenziell umfangreicher.
 
 
 	SLOC	Zeilen	Bytes	Gehoert zu  	Dateidatum	Kategorie
 	-----------------------------------------------------------------
-	116	123	 2966	System III	1980-04-11	(trad)
-	118	125	 3038	4.3BSD-UWisc	1986-11-07	(trad)
-	200	256	 5715	4.3BSD-Reno	1990-06-25	(trad)
-	200	270	 6545	NetBSD	 	1993-03-21	(trad)
+	116	123	 2966	System III	1980-04-11	(hist)
+	118	125	 3038	4.3BSD-UWisc	1986-11-07	(hist)
+	200	256	 5715	4.3BSD-Reno	1990-06-25	(hist)
+	200	270	 6545	NetBSD	 	1993-03-21	(hist)
 	218	290	 6892	OpenBSD		2008-06-27	(pseudo)
-	224	296	 6920	FreeBSD		1994-05-27	(trad)
+	224	296	 6920	FreeBSD		1994-05-27	(hist)
 	232	306	 7500	NetBSD 		2014-02-03	(pseudo)
 	340	405	 7423	Heirloom	2012-05-20	(POSIX)
 	382	586	14175	GNU coreutils	1992-11-08	(pseudo)
@@ -352,8 +357,8 @@
 urspruenglichen Implementierungen, die sich nur minimal
 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
-die alte GNU-Version mit 340-390 SLOCs. Und (4) die moderne
-GNU-Variante mit fast 600 SLOCs.
+die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
+moderne GNU-Variante mit fast 600 SLOCs.
 
 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
@@ -366,15 +371,15 @@
 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
-fast 40 nach oben. Dies liegt bei GNU hauptsaechlich an deren
+fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren
 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
 Ob man die Heirloom-Implementierung als besonders kryptisch
 oder als besonders elegant bezeichnen will, das soll der
 eigenen Einschaetzung des Lesers ueberlassen bleiben.
 
 
-Die interne Struktur des C-Codes ist meist aehnlich. Neben der
-obligatorischen main-Funktion, die die Kommandozeilenargumente
+Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
+Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
 verarbeitet, gibt es im Normalfall eine Funktion, die die
 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
 haben fast alle Implementierungen separate Funktionen fuer die
@@ -382,28 +387,28 @@
 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
-wird ausser den Fehlerausgaben nichts aus der main-Funktion
-ausgelagert.
+wird ausser den Fehlerausgaben alles in der main-Funktion
+erledigt.
 
 Cut-Implementierungen haben typischerweise zwei limitierende
 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
-Zeilenlaenge. Bei System III ist die Anzahl der moeglichen Felder
-und ebenso die Zeilenlaenge auf 512 begrenzt. 4.3BSD-Reno und die
-BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX
-bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei
-allen GNU-Implementierungen und bei Heirloom kann sowohl
-die Felderanzahl als auch die maximale Zeilenlaenge beliebig
-gross werden; der Speicher dafür wird dynamisch alloziiert.
-OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber
-beliebiger Zeilenlaenge. Die begrenzte Felderanzahl scheint
-jedoch kein praktisches Problem darzustellen, da _POSIX2_LINE_MAX
-mit mindestens 2048 durchaus genug Platz bieten sollte.
+Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt.
+4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
+Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
+FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
+Heirloom kann sowohl die Felderanzahl als auch die maximale
+Zeilenlaenge beliebig gross werden; der Speicher dafür wird
+dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
+Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
+begrenzte Felderanzahl scheint jedoch kein Praxisproblem
+darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
+gross genug sein sollte.
 
 
 Beschreibungen
 
 Interessant ist auch ein Vergleich der Kurzbeschreibungen von
-cut, wie sie sich in der Titelzeile von Manpages oder manchmal
+cut, wie sie sich in der Titelzeile der Manpages oder manchmal
 auch am Anfang der Quellcodedatei finden. Die folgende Liste
 ist grob zeitlich geordnet und nach Abstammung gruppiert:
 
@@ -436,32 +441,30 @@
 
 
 Die mit ``(src)'' markierten Beschreibungen sind aus dem
-jeweiligen Quellcode entnommen.
-Der POSIX-Eintrag enthaelt die Beschreibung des Standards.
-Der ``Unix Reader'' ist ein rueckblickendes Textdokument von
-Doug McIlroy, das das Auftreten von Tools in der Geschichte
-des Research Unix zum Thema hat.
+jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
+die Beschreibung des Standards. Der ``Unix Reader'' ist ein
+rueckblickendes Textdokument von Doug McIlroy, das das
+Auftreten von Tools in der Geschichte des Research Unix zum
+Thema hat.
 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
-Eigentlich sollte seine
-Beschreibung der in Version 8 Unix entsprechen. Die
-Abweichung koennte sowohl ein Uebertragungsfehler als auch
-eine nachtraegliche Korrektur sein.
-Alle uebrigen Beschreibungen entstammen den Manpages.
+Eigentlich sollte seine Beschreibung der in Version 8 Unix
+entsprechen. Die Abweichung koennte sowohl ein
+Uebertragungsfehler als auch eine nachtraegliche Korrektur
+sein. Alle uebrigen Beschreibungen entstammen den Manpages.
 
 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
-oder zumindest an sie angeglichen worden, wie beispielsweise
-bei FreeBSD.
+oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
 
 Interessant ist, dass die GNU coreutils seit Anbeginn vom
 Entfernen von Teilen der Eingabe sprechen, wohingegen die
 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
-Worte ``cut out'' sind vielleicht auch nur etwas zu
+Worte ``cut out'' sind vielleicht auch etwas zu
 missverstaendlich. HP-UX hat sie deshalb praezisiert.
 
 Auch beim Begriff, was selektiert wird, ist man sich
-uneins. Die einen reden von Feldern (POSIX), andere von
-Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten
+uneins. Die Einen reden von Feldern (POSIX), Andere von
+Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
 (Research Unix). Ironischerweise leistet sich gerade Version
 8 Unix, das eigentlich um eine sehr treffende Weltsicht
 bemueht ist, mit ``rearrange columns of data'' die