--- a/cut.txt	Thu May 28 06:34:21 2015 +0200
+++ b/cut.txt	Thu May 28 06:41:08 2015 +0200
@@ -6,16 +6,16 @@
 
 Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
 In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
-es, denn es ist ein schoenes, praktisches und anschauliches
+es, denn es ist ein schönes, praktisches und anschauliches
 Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
 werden.
 
 
 Funktionsweise
 
-Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten
-erweitert wurden. Cut schneidet entweder gewuenschte Zeichen aus
-den Zeilen der Eingabe oder gewuenschte, durch Trennzeichen
+Ursprünglich hatte cut zwei Modi, die später um einen dritten
+erweitert wurden. Cut schneidet entweder gewünschte Zeichen aus
+den Zeilen der Eingabe oder gewünschte, durch Trennzeichen
 definierte, Felder.
 
 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
@@ -35,24 +35,24 @@
 	$ ls -l | cut -c 3,6,9
 	ww-
 
-Mit cut lassen sich aber auch Strings kuerzen.
+Mit cut lassen sich aber auch Strings kürzen.
 
 	$ long=12345678901234567890
 	$ echo "$long" | cut -c -10
 	1234567890
 
 Dieser Befehl gibt die ersten maximal 10 Zeichen von
-`$long' aus. (Alternativ kann man hierfuer `printf
+`$long' aus. (Alternativ kann man hierfür `printf
 "%.10s\n" "$long"' verwenden.)
 
 Geht es aber nicht um die Darstellung von Zeichen, sondern um
 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
-Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung
+Früher, als US-ASCII noch die omnipräsente Zeichenkodierung
 war, wurde jedes Zeichen mit genau einem
-Byte gespeichert. Somit selektierte `cut -c' gleichermassen
+Byte gespeichert. Somit selektierte `cut -c' gleichermaßen
 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
-dieser Annahme loesen. In diesem Zug bekam cut mit
+dieser Annahme lösen. In diesem Zug bekam cut mit
 POSIX.2-1992 einen Bytemodus (Option `-b'). Will man
 also nur die ersten maximal 500 Bytes vor dem
 Newline-Zeichen stehen haben (und den Rest stillschweigend
@@ -61,11 +61,11 @@
 	$ cut -b -500
 
 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese
-Funktion ist insbesondere fuer POSIX wichtig, da man damit
-Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
+Funktion ist insbesondere für POSIX wichtig, da man damit
+Textdateien mit begrenzter Zeilenlänge erzeugen kann.
 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
 
-Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte
+Wenn auch der Bytemodus neu eingeführt 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
@@ -74,11 +74,11 @@
 
 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 in
-gleicher Weise fuer die Eingabe und die Ausgabe.
+können Felder ausgewählt werden. Das Trennzeichen (per
+Default der Tab) kann mit `-d' geändert werden. Es gilt in
+gleicher Weise für die Eingabe und die Ausgabe.
 
-Der typische Anwendungsfall fuer cut im Feldmodus ist die
+Der typische Anwendungsfall für cut im Feldmodus ist die
 Auswahl von Information aus der passwd-Datei. Hier z.B. der
 Benutzername und seine ID:
 
@@ -89,27 +89,27 @@
 	mail:8
 	...
 
-(Die Argumente fuer die Optionen koennen bei cut uebrigens
-mit Whitespace abgetrennt oder direkt angehaengt folgen.)
+(Die Argumente für die Optionen können bei cut übrigens
+mit Whitespace abgetrennt oder direkt angehängt folgen.)
 
-Dieser Feldmodus ist fuer einfache tabellarische Dateien,
+Dieser Feldmodus ist für einfache tabellarische Dateien,
 wie eben die passwd, gut geeignet. Er kommt aber schnell an
-seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
+seine Grenzen. Gerade der häufige 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
 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
+stehende Trennzeichen führen 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 deshalb Erweiterungen, die das gewuenschte Verhalten
-fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
+haben deshalb Erweiterungen, die das gewünschte Verhalten
+für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
 man portabel bleiben will, verwendet man awk in diesen
-Faellen.
+Fällen.
 
 Awk bietet noch eine weitere Funktion, die cut missen
-laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
+lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
 Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt
 der Aufruf
@@ -121,8 +121,8 @@
 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 demnach die Datenbankoperation Projektion auf
-Textdateien aus. Die Wikipedia erklaert das folgendermassen:
+Cut führt demnach die Datenbankoperation Projektion auf
+Textdateien aus. Die Wikipedia erklärt das folgendermaßen:
 
 	Die Projektion entspricht der Projektionsabbildung aus der
 	Mengenlehre und kann auch Attributbeschränkung genannt
@@ -137,28 +137,28 @@
 Geschichtliches
 
 Cut erblickte 1982 mit dem Release von UNIX System III das
-Licht der oeffentlichen Welt. Wenn man die Quellen von System
+Licht der öffentlichen Welt. Wenn man die Quellen von System
 III durchforstet, findet man die Quellcodedatei cut.c mit dem
 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 SCCS-ID im
+Das ist die älteste Manifestation des Programms, die ich
+aufstöbern konnte. Allerdings spricht die SCCS-ID im
 Quellcode von Version 1.5. Die Vorgeschichte liegt, der Aussage
 Doug McIlroys
 [ XXX
-zufolge, in PWB/UNIX, das die Grundlage fuer System III war.
+zufolge, in PWB/UNIX, das die Grundlage für System III war.
 (PWB 3.0 entspricht System III.) In den von PWB 1.0 (1977)
-verfuegbaren Quellen
+verfügbaren Quellen
 [ XXX
 ist cut noch nicht zu finden; von PWB 2.0 sind mir keine
-verfuegbaren Quellen oder hilfreiche Dokumentation bekannt.
+verfügbaren Quellen oder hilfreiche Dokumentation bekannt.
 
-Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester
+Nun ein Blick auf die BSD-Linie: Dort ist mein frühester
 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 im Januar 1987 veröffentlicht wurde.
 Die Implementierung unterscheidet sich nur minimal von der
 in System III.
 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
@@ -169,12 +169,12 @@
 [ 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.
+erwähnt bereits die erwartete Konformität mit POSIX.2.
 Nun muss man wissen, dass POSIX.2 erst im September
-1992 veroeffentlicht wurde, erst gut zwei Jahren nachdem die
+1992 veröffentlicht 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.
+implementiert. Ein Blick in den Code bekräftigt diese Vermutung.
 In der Funktion zum parsen der Feldauswahlliste findet sich
 dieser Kommentar:
 
@@ -182,61 +182,61 @@
 	POSIX doesn't allow lists that aren't in increasing order or
 	overlapping lists.
 
-Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits
+Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits
 ein:
 
 	The elements in list can be repeated, can overlap, and can
 	be specified in any order.
 
-Zudem listet Draft 11.2 alle drei Modi, waehrend in diesem
-BSD cut nur die zwei alten implementiert sind. Es koennte also
+Zudem listet Draft 11.2 alle drei Modi, während in diesem
+BSD cut nur die zwei alten implementiert sind. Es könnte 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.
+leider nicht möglich, diese Vermutung zu prüfen.
 
-Die Versionsnummern und Aenderungsdaten der aelteren
+Die Versionsnummern und Änderungsdaten der älteren
 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
-damaligen Versionskontrollsystem in den Code eingefuegt wurden,
+damaligen Versionskontrollsystem in den Code eingefügt wurden,
 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
 
-Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
+Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:
 
 	Copyright (C) 1997-2015 Free Software Foundation, Inc.
 	Copyright (C) 1984 David M. Ihnat
 
-Der Code hat also recht alte Urspruenge. Wie aus weiteren
+Der Code hat also recht alte Ursprünge. Wie aus weiteren
 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
-MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
+MacKenzie und später von Jim Meyering überarbeitet. Letzterer
 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
 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.
-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 noch nicht
+Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut,
+aus Sicht des ursprünglichen Unix, zu den jüngeren Tools.
+Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist,
+so war Unix doch schon über zehn Jahre alt, als cut das
+erste Mal auftauchte. Insbesondere gehörte 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
-fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
+fragen, warum cut überhaupt noch entwickelt wurde, wo es
 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
+konnten. Ein Argument für cut war sicher seine Kompaktheit und
+die damit verbundene Geschwindigkeit gegenüber dem damals
+trägen 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.
+Cut überzeugte. Es wurde in andere Unix Varianten übernommen,
+standardisiert und ist heutzutage überall anzutreffen.
 
-Die urspruengliche Variante (ohne -b) wurde schon 1985 in
+Die ursprüngliche Variante (ohne -b) wurde schon 1985 in
 der System V Interface Definition, einer wichtigen formalen
 Beschreibung von UNIX System V, spezifiziert und tauchte
-anschliessend in allen relevanten Standards auf. Mit POSIX.2
+anschließend in allen relevanten Standards auf. Mit POSIX.2
 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
 (mit -b) standardisiert.
 
 
-Multibyte-Unterstuetzung
+Multibyte-Unterstützung
 
 Nun sind der Bytemodus und die damit verbundene
 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
@@ -245,11 +245,11 @@
 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
+für -c handhaben. Diese Implementierungen funktionieren mit
 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
-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
+Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber
+wie -b (und -n wird ignoriert). Schließlich gibt es noch
+Implementierungen, die -b und -c tatsächlich POSIX-konform
 implementieren.
 
 Historische Zwei-Modi-Implementierungen sind z.B. die von
@@ -257,11 +257,11 @@
 
 Pseudo-Multibyte-Implementierungen bieten GNU und die
 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
-ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
+ob dort ein Schein von POSIX-Konformität gewahrt wird.
 Teilweise findet man erst nach genauerer Suche heraus, dass
 -c und -n nicht wie erwartet funktionieren; teilweise machen es
 sich die Systeme auch einfach, indem sie auf
-Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
+Singlebyte-Zeichenkodierungen beharren, das aber dafür meist
 klar darlegen:
 
 	Since we don't support multi-byte characters, the -c and -b
@@ -269,20 +269,20 @@
 
 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
 
-Tatsaechlich standardkonforme Implementierungen, die
+Tatsächlich standardkonforme Implementierungen, die
 Multibytes korrekt handhaben, bekommt man bei einem modernen
 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
-Warum die beiden anderen grossen BSDs diese Aenderung nicht
-uebernommen haben, bleibt offen. Es scheint aber an der im
+Warum die beiden anderen großen BSDs diese Änderung nicht
+übernommen haben, bleibt offen. Es scheint aber an der im
 obigen Kommentar formulierten Grundausrichtung zu liegen.
 
 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
-Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
+Systems Multibytes korrekt unterstützt werden? Zuerst ist
 entscheidend, ob das System selbst mit einem Multibyte-Encoding
 arbeitet, denn tut es das nicht, dann entsprechen sich
-Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
+Zeichen und Bytes und die Frage erübrigt sich. Man kann das
 herausfinden indem man sich das Locale anschaut, aber einfacher
 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
 auszugeben und zu schauen ob dieses in einem oder in mehreren
@@ -293,7 +293,7 @@
 	0000003
 
 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
-Zeilenumbruch fuegt echo(1) hinzu.)
+Zeilenumbruch fügt echo(1) hinzu.)
 
 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
@@ -311,7 +311,7 @@
 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 folgendermassen
+dann sollte sich eine POSIX-konforme Implementierung folgendermaßen
 verhalten:
 
 	$ echo ä | cut -c 1 | od -c
@@ -327,7 +327,7 @@
 	0000001
 
 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
-allen drei Faellen wie die mittlere: Es wird das erste Byte
+allen drei Fällen wie die mittlere: Es wird das erste Byte
 ausgegeben.
 
 
@@ -336,15 +336,15 @@
 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
 Implementierungen.
 
-Fuer einen ersten Eindruck ist der Umfang des Quellcodes
-hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
+Für einen ersten Eindruck ist der Umfang des Quellcodes
+hilfreich. Typischerweise steigt dieser über die Jahre an. Diese
 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
-bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
-erfordert zwangslaeufig mehr Code, deshalb sind diese
+bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
+erfordert zwangsläufig mehr Code, deshalb sind diese
 Implementierungen tendenziell umfangreicher.
 
 
-	SLOC	Zeilen	Bytes	Gehoert zu  	Dateidatum	Kategorie
+	SLOC	Zeilen	Bytes	Gehört zu  	Dateidatum	Kategorie
 	-----------------------------------------------------------------
 	116	123	 2966	System III	1980-04-11	(hist)
 	118	125	 3038	4.3BSD-UWisc	1986-11-07	(hist)
@@ -360,56 +360,60 @@
 
 
 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
-urspruenglichen Implementierungen, die sich nur minimal
-unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
+ursprünglichen Implementierungen, die sich nur minimal
+unterscheiden, mit gut 100 SLOCs. (2) Die fünf BSD-Versionen mit
 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
-die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
+die alte GNU-Version mit 340-390 SLOCs. Und schließlich (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
--l') erstreckt sich ueber eine Spanne von Faktor 1.06 bei den
-aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Den groessten
+SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (`wc
+-l') erstreckt sich über eine Spanne von Faktor 1.06 bei den
+ältesten Vertretern bis zu Faktor 1.5 bei GNU. Den größten
 Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und
-die Groesse des Lizenzblocks am Dateianfang. 
+die Größe des Lizenzblocks am Dateianfang. 
 
 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
-und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
+und der Dateigröße (`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. Bei GNU liegt dies hauptsaechlich an deren
-Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
-Ob man die Heirloom-Implementierung als besonders kryptisch
+fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren
+Programmierstil, mit spezieller Einrückung und langen Bezeichnern.
+Ob man die Heirloom-Implementierung
+[ XXX
+als besonders kryptisch
 oder als besonders elegant bezeichnen will, das soll der
-eigenen Einschaetzung des Lesers ueberlassen bleiben. Vor allem
-der Vergleich mit einer GNU-Implementierung ist eindrucksvoll.
+eigenen Einschätzung des Lesers überlassen bleiben. Vor allem
+der Vergleich mit einer GNU-Implementierung
+[ XXX
+ist eindrucksvoll.
 
 
-Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
+Die interne Struktur der Programmcodes (in C) ist meist ähnlich.
 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
+Feldauswahl in eine interne Datenstruktur überführt. Desweiteren
+haben fast alle Implementierungen separate Funktionen für die
 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
+damit in einer eigenen Funktion umgesetzt. Nur bei der frühen
 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
-wird ausser den Fehlerausgaben alles in der main-Funktion
+wird außer 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 sind beide Groessen auf 512 begrenzt.
+Größen: Die Maximalanzahl unterstützter Felder und die maximale
+Zeilenlänge. Bei System III sind beide Größen 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 dafuer wird
+Zeilenlänge beliebig groß werden; der Speicher dafür wird
 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
-Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
+Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die
 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
-gross genug sein sollte.
+groß genug sein sollte.
 
 
 Beschreibungen
@@ -448,44 +452,44 @@
 
 
 Die mit ``(src)'' markierten Beschreibungen sind aus dem
-jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
+jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält
 die Beschreibung im Standard. Der ``Unix Reader'' ist ein
-rueckblickendes Textdokument von Doug McIlroy, das das
+rückblickendes Textdokument von Doug McIlroy, das das
 Auftreten der 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 ein Uebertragungsfehler
-oder eine nachtraegliche Korrektur sein. Alle uebrigen
+entsprechen. Die Abweichung könnte ein Übertragungsfehler
+oder eine nachträgliche Korrektur sein. Alle übrigen
 Beschreibungen entstammen den Manpages.
 
-Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
+Oft ist mit der Zeit die POSIX-Beschreibung übernommen
 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 zu missverstaendlich.
-HP-UX hat sie deshalb praezisiert.
+Kommandozeilenangabe klar ein Auswählen darstellt. Die
+Worte ``cut out'' sind vielleicht auch zu missverständlich.
+HP-UX hat sie deshalb präzisiert.
 
 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
 8 Unix, das eigentlich um eine sehr treffende Weltsicht
-bemueht ist, mit ``rearrange columns of data'' die
+bemüht ist, mit ``rearrange columns of data'' die
 unzutreffendste der Beschreibungen.
 
 
 Autoreninfo
 
-Markus Schnalke interessiert sich fuer die Hintergruende
-von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses
+Markus Schnalke interessiert sich für die Hintergründe
+von Unix und seinen Werkzeugen. Für die Erarbeitung dieses
 Textes wurde er regelrecht zum Historiker.
 
 
 Lizenz
 
 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
-veroeffentlicht werden)
+veröffentlicht werden)