--- a/cut.txt	Tue May 12 06:46:59 2015 +0200
+++ b/cut.txt	Tue May 12 07:35:33 2015 +0200
@@ -1,5 +1,3 @@
-Das Werkzeugkaestle, #1
-
 cut - cut out selected fields of each line of a file
 ----------------------------------------------------
 markus schnalke <meillo@marmaro.de>
@@ -25,6 +23,9 @@
 Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in
 diesem Beispiel die Rechte des Besitzers:
 
+	$ ls -l foo
+	-rw-rw-r-- 1 meillo users 0 May 12 07:32 foo
+
 	$ ls -l foo | cut -c 2-4
 	rw-
 
@@ -41,7 +42,7 @@
 	1234567890
 
 Dieser Befehl gibt die ersten maximal 10 Zeichen von
-`$long' aus. (Alternativ kann man hierfuer auch `printf
+`$long' aus. (Alternativ kann man hierfuer `printf
 "%.10s\n" "$long"' verwenden.)
 
 Geht es aber nicht um die Darstellung von Zeichen, sondern um
@@ -109,16 +110,7 @@
 Awk bietet noch eine weitere Funktion, die cut missen
 laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
-Feld kann selbst mehrfach angegeben werden.
-
-XXX
-4.3BSD-Reno + *BSDs
-         * This parser is less restrictive than the Draft 9 POSIX spec.
-         * POSIX doesn't allow lists that aren't in increasing order or
-         * overlapping lists.  We also handle "-3-5" although there's no
-         * real reason too.
-
-So gibt der Aufruf
+Feld kann selbst mehrfach angegeben werden. So gibt der Aufruf
 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
 der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
@@ -172,31 +164,29 @@
 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?
+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
 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
 Manpage und das Programm geschrieben wurden. Das Programm
 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.
+implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
+In der Funktion zum parsen der Feldauswahlliste findet sich
+dieser Kommentar:
 
-XXX
-Schaut man sich die SCCS-IDs (die vom damaligen
-Versionskontrollsystem eingefuegt wurden) in den BSD-Quellen an,
-dann findet man dort Versionsnummern, die die Entstehung
-dokumentieren:
+	This parser is less restrictive than the Draft 9 POSIX spec.
+	POSIX doesn't allow lists that aren't in increasing order or
+	overlapping lists.
 
-	4.3BSD-UWisc	"@(#)cut.c      1.3";
-	4.3BSD-Reno	"@(#)cut.c      5.3 (Berkeley) 6/24/90";
-	NetBSD		"@(#)cut.c      5.4 (Berkeley) 10/30/90";
-	FreeBSD		"@(#)cut.c      8.1 (Berkeley) 6/6/93";
+Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits
+ein:
 
-Die neueren BSD-Versionen enthalten zwar weiterhin eine SCCS-ID, diese
-ist aber bei Version "8.3 (Berkeley) 5/4/95" stehen geblieben. Danach
-wurde scheinbar von SCCS auf ein anderes
-Versionskontrollsystem gewechselt.
-XXX
+	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)
+ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
 
 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
 
@@ -233,7 +223,7 @@
 anschliessend in allen relevanten Standards auf. Mit POSIX.2
 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
 (mit -b) standardisiert.
-XXX sicher? s.o.
+XXX sicher?
 
 
 Multibyte-Unterstuetzung
@@ -256,14 +246,18 @@
 System III, System V und die aller BSDs bis in die 90er.
 
 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:
+modernen NetBSDs und OpenBSDs. Man darf sich durchaus 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:
 
-	/* Since we don't support multi-byte characters, the -c and -b 
-	   options are equivalent, and the -n option is meaningless. */
+	Since we don't support multi-byte characters, the -c and -b
+	options are equivalent, and the -n option is meaningless.
 
-[ XXX
+[ openbsd XXX
 
 Tatsaechlich standardkonforme Implementierungen, die
 Multibytes korrekt handhaben, bekommt man bei einem modernen
@@ -392,16 +386,20 @@
 wird ausser den Fehlerausgaben nichts aus der main-Funktion
 ausgelagert.
 
-XXX
-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
+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 (fgetln). XXX
+beliebiger Zeilenlaenge. XXX fgetln
+Die begrenzte Felderanzahl scheint jedeoch kein praktisches
+Problem darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048
+durchaus genug Platz bieten sollte.
 
 
 Beschreibungen