--- a/cut.txt	Tue May 19 07:30:07 2015 +0200
+++ b/cut.txt	Tue May 19 08:04:05 2015 +0200
@@ -19,7 +19,7 @@
 definierte, Felder.
 
 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
-zerteilen. So kann man damit beispielsweise bestimmte
+zerteilen. Man kann damit beispielsweise bestimmte
 Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in
 diesem Beispiel die Rechte des Besitzers:
 
@@ -61,7 +61,7 @@
 	$ cut -b -500
 
 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese
-Funktion ist insbesondere fuer POSIX wichtig, da man so
+Funktion ist insbesondere fuer POSIX wichtig, da man damit
 Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
 
@@ -69,17 +69,17 @@
 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
+war folglich nicht, den neuen Bytemodus zu implementieren, sondern
 den Zeichenmodus neu zu implementieren.
 
 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. Es gilt sowohl
-fuer die Eingabe als auch fuer die Ausgabe.
+Default der Tab) kann mit `-d' geaendert werden. Es gilt in
+gleicher Weise fuer die Eingabe und die Ausgabe.
 
 Der typische Anwendungsfall fuer cut im Feldmodus ist die
-Auswahl von Information aus der passwd-Datei. So z.B. der
+Auswahl von Information aus der passwd-Datei. Hier z.B. der
 Benutzername und seine ID:
 
 	$ cut -d: -f1,3 /etc/passwd
@@ -97,8 +97,8 @@
 seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
 in Felder geteilt werden soll, wird damit nicht abgedeckt.
 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
+demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
+werden. Zudem 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
@@ -111,16 +111,17 @@
 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. So gibt der Aufruf
+Feld kann selbst mehrfach angegeben werden. Dementsprechend 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
 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
-dabei immer gleich geordnet wie in der Eingabe. Um die Worte
+hierbei immer gleich geordnet wie in der Eingabe. Um die Worte
 der Manpage von Version 8 Unix wiederzugeben: ``In data base
 parlance, it projects a relation.''
 [ http://man.cat-v.org/unix_8th/1/cut
-Cut fuehrt also die Datenbankoperation Projektion auf
+Cut fuehrt demnach die Datenbankoperation Projektion auf
 Textdateien aus. Die Wikipedia erklaert das folgendermassen:
 
 	Die Projektion entspricht der Projektionsabbildung aus der
@@ -142,7 +143,7 @@
 [ 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 SCCS-ID im
-Quellcode von Version 1.5. Es muss also noch eine
+Quellcode von Version 1.5. Es muss demzufolge noch eine
 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
 gefunden.
 XXX mail an TUHS
@@ -165,7 +166,7 @@
 [ 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.
 Nun muss man wissen, dass POSIX.2 erst im September
-1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
+1992 veroeffentlicht wurde, erst gut zwei Jahren nachdem die
 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.
@@ -182,7 +183,7 @@
 	The elements in list can be repeated, can overlap, and can
 	be specified in any order.
 
-Auch listet Draft 11.2 alle drei Modi, waehrend in diesem
+Zudem 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
@@ -209,7 +210,7 @@
 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
+erste Mal auftauchte. Insbesondere gehoerte cut noch nicht
 zu Version 7 Unix, das die Ausgangsbasis aller modernen
 Unix-Systeme darstellt. Die weit komplexeren Programme sed
 und awk waren dort schon vertreten. Man muss sich also
@@ -364,8 +365,8 @@
 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
 -l') erstreckt sich ueber eine Spanne von Faktor 1.06 bei den
-aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Der groesste
-Einflussfaktor darauf haben Leerzeilen, reine Kommentarzeilen und
+aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Den groessten
+Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und
 die Groesse des Lizenzblocks am Dateianfang. 
 
 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
@@ -385,7 +386,7 @@
 verarbeitet, gibt es im Normalfall eine Funktion, die die
 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
 haben fast alle Implementierungen separate Funktionen fuer die
-zwei bzw. drei Modi. Bei den POSIX-konformen Implementierungen
+zwei oder drei Modi. Bei den POSIX-konformen Implementierungen
 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)
@@ -409,9 +410,9 @@
 
 Beschreibungen
 
-Interessant ist auch ein Vergleich der Kurzbeschreibungen von
+Interessant ist zudem ein Vergleich der Kurzbeschreibungen von
 cut, wie sie sich in der Titelzeile der Manpages oder manchmal
-auch am Anfang der Quellcodedatei finden. Die folgende Liste
+am Anfang der Quellcodedatei finden. Die folgende Liste
 ist grob zeitlich geordnet und nach Abstammung gruppiert:
 
 
@@ -450,9 +451,9 @@
 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.
+entsprechen. Die Abweichung koennte ein Uebertragungsfehler
+oder eine nachtraegliche Korrektur sein. Alle uebrigen
+Beschreibungen entstammen den Manpages.
 
 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
@@ -461,10 +462,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 zu
-missverstaendlich. HP-UX hat sie deshalb praezisiert.
+Worte ``cut out'' sind vielleicht auch zu missverstaendlich.
+HP-UX hat sie deshalb praezisiert.
 
-Auch beim Begriff, was selektiert wird, ist man sich
+Beim Begriff, was selektiert wird, ist man sich ebenfalls
 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