--- a/cut.txt	Tue May 05 19:21:00 2015 +0200
+++ b/cut.txt	Mon May 11 07:09:00 2015 +0200
@@ -36,11 +36,13 @@
 
 Mit cut lassen sich aber auch Strings kuerzen.
 
-	$ echo "$long" | cut -c -20
+	$ long=12345678901234567890
+	$ echo "$long" | cut -c -10
+	1234567890
 
-Dieser Befehl gibt die ersten maximal 20 Zeichen von
+Dieser Befehl gibt die ersten maximal 10 Zeichen von
 `$long' aus. (Alternativ kann man hierfuer auch `printf
-"%.20s\n" "$long"' verwenden.)
+"%.10s\n" "$long"' verwenden.)
 
 Geht es aber nicht um die Darstellung von Zeichen, sondern um
 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
@@ -62,14 +64,21 @@
 Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
 
-Neben dem Zeichen- bzw. Byte-Modus bietet cut noch den
+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
+den Zeichenmodus neu zu implementieren.
+
+Neben dem Zeichen- und Byte-Modus bietet cut noch den
 Feld-Modus, 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
 Auswahl von Information aus der passwd-Datei. So z.B. der
-Benutername, seine ID und das Homeverzeichnis:
+Benutzername, seine ID und das Homeverzeichnis:
 
 	$ cut -d: -f1,3,6 /etc/passwd
 	root:0:/root
@@ -110,8 +119,7 @@
 parlance, it projects a relation.''
 [ XXX
 Cut fuehrt also die Datenbankoperation Projektion auf
-Textdateien aus. Die Wikipedia erklaert das in
-verstaendlicherer Sprache:
+Textdateien aus. Die Wikipedia erklaert das folgendermassen:
 
 	Die Projektion entspricht der Projektionsabbildung aus der
 	Mengenlehre und kann auch Attributbeschränkung genannt
@@ -137,7 +145,7 @@
 gefunden.
 XXX mail an TUHS
 
-Aber werfen wir doch einen Blick auf die BSD-Linie: Dort ist mein
+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
@@ -157,9 +165,9 @@
 erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
 XXX 2 oder 3 modi?
 Nun sollte man wissen, dass POSIX.2 erst im September
-1992 veroeffentlicht wurde, also gut zwei Jahren *nachdem* die
+1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
 Manpage und das Programm geschrieben wurden. Das Programm
-wurde also anhand von Arbeitsversionen des Standards
+wurde folglich anhand von Arbeitsversionen des Standards
 implementiert. Zweieinhalb Jahre Arbeit war immerhin schon in
 den Standardisierungsprozess geflossen; bis zur
 Fertigstellung sollte es aber noch weitere zwei Jahre dauern.
@@ -167,8 +175,8 @@
 Das cut der GNU Coreutils enthaelt einen Copyrightvermerk von
 David M. Ihnat aus dem Jahr 1984.
 
-Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut
-aus Sicht des urspruenglichen Unix zu den juengeren Tools.
+Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut,
+aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
 so war Unix doch schon ueber zehn Jahre alt, als cut das
 erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht
@@ -198,10 +206,10 @@
 Nun sind der Bytemodus und die damit verbundene
 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
 1992 standardisiert, wie steht es aber mit deren Umsetzung?
-Welche Versionen implementieren denn den POSIX korrekt?
+Welche Versionen implementieren POSIX korrekt?
 Die Situation ist dreiteilig: Es gibt traditionelle
 Implementierungen, die nur -c und -f kennen. Dann gibt es
-Implementierungen die zwar -b kennen, es aber nur als Alias
+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
@@ -212,7 +220,7 @@
 Traditionelle Zwei-Modi-Implementierungen sind z.B. die von
 System III, System V und die aller BSDs bis in die 90er.
 
-Pseude-Multibyte-Implementierungen bieten GNU und die
+Pseudo-Multibyte-Implementierungen bieten GNU und die
 modernen NetBSDs und OpenBSDs. Wie sehr dort ein Schein von
 POSIX-Konformitaet gewahrt wird, ist unterschiedlich. Nicht
 immer findet man klare Aussagen wie diese:
@@ -249,8 +257,8 @@
 Zeilenumbruch fuegt echo(1) hinzu.)
 
 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
-Kodierungen konvertieren. Hier Beispiele, wie das Ergebnis
-bei Latin1 und wie es bei UTF-8 aussieht.
+Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
+bei Latin1 und wie sie bei UTF-8 aussieht.
 
 	$ echo ä | iconv -t latin1 | od -c        
 	0000000 344  \n
@@ -266,21 +274,21 @@
 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
 dann sollte sich eine POSIX-konforme Implementierung so verhalten:
 
-	$ echo aä | ./cut -c -2 | od -c
-	0000000   a 303 244  \n
-	0000004
-
-	$ echo aä | ./cut -b -2 | od -c
-	0000000   a 303  \n
+	$ echo ä | ./cut -c 1 | od -c
+	0000000 303 244  \n
 	0000003
 
-	$ echo aä | ./cut -b -2 -n | od -c
-	0000000   a  \n
+	$ echo ä | ./cut -b 1 | od -c
+	0000000 303  \n
 	0000002
 
-Bei einer Implementierung, die -b und -c gleich behandelt,
-ist die Ausgabe in allen drei Faellen wie die mittlere: Es
-werden die ersten beiden Bytes ausgegeben.
+	$ echo ä | ./cut -b 1 -n | od -c
+	0000000  \n
+	0000001
+
+Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
+allen drei Faellen wie die mittlere: Es wird das erste Byte
+ausgegeben.
 
 
 Implementierungen
@@ -330,7 +338,7 @@
 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 am
+fast 40 nach oben. Dies liegt bei GNU 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
@@ -384,10 +392,9 @@
 NetBSD		select portions of each line of a file
 OpenBSD 4.6	select portions of each line of a file
 FreeBSD 1.0	select portions of each line of a file
-FreeBSD 7.0	cut out selected portions of each line of a file
+FreeBSD 10.0	cut out selected portions of each line of a file
 SunOS 4.1.3	remove selected fields from each line of a file
 SunOS 5.5.1	cut out selected fields of each line of a file
-XXX FreeBSD 10
 
 Heirloom Tools	cut out selected fields of each line of a file
 Heirloom Tools (src)	cut out fields of lines of files
@@ -423,10 +430,10 @@
 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 etwas
+Worte ``cut out'' sind vielleicht auch nur etwas zu
 missverstaendlich. HP-UX hat sie deshalb praezisiert.
 
-Auch beim Begriff, was denn nun selektiert wird, ist man sich
+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
 (Research Unix). Ironischerweise leistet sich gerade Version
@@ -443,5 +450,6 @@
 
 
 Lizenz
+
 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
 veroeffentlicht werden)