1.1 --- a/cut.txt	Thu May 28 06:34:21 2015 +0200
     1.2 +++ b/cut.txt	Thu May 28 06:41:08 2015 +0200
     1.3 @@ -6,16 +6,16 @@
     1.4  
     1.5  Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
     1.6  In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
     1.7 -es, denn es ist ein schoenes, praktisches und anschauliches
     1.8 +es, denn es ist ein schönes, praktisches und anschauliches
     1.9  Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
    1.10  werden.
    1.11  
    1.12  
    1.13  Funktionsweise
    1.14  
    1.15 -Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten
    1.16 -erweitert wurden. Cut schneidet entweder gewuenschte Zeichen aus
    1.17 -den Zeilen der Eingabe oder gewuenschte, durch Trennzeichen
    1.18 +Ursprünglich hatte cut zwei Modi, die später um einen dritten
    1.19 +erweitert wurden. Cut schneidet entweder gewünschte Zeichen aus
    1.20 +den Zeilen der Eingabe oder gewünschte, durch Trennzeichen
    1.21  definierte, Felder.
    1.22  
    1.23  Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
    1.24 @@ -35,24 +35,24 @@
    1.25  	$ ls -l | cut -c 3,6,9
    1.26  	ww-
    1.27  
    1.28 -Mit cut lassen sich aber auch Strings kuerzen.
    1.29 +Mit cut lassen sich aber auch Strings kürzen.
    1.30  
    1.31  	$ long=12345678901234567890
    1.32  	$ echo "$long" | cut -c -10
    1.33  	1234567890
    1.34  
    1.35  Dieser Befehl gibt die ersten maximal 10 Zeichen von
    1.36 -`$long' aus. (Alternativ kann man hierfuer `printf
    1.37 +`$long' aus. (Alternativ kann man hierfür `printf
    1.38  "%.10s\n" "$long"' verwenden.)
    1.39  
    1.40  Geht es aber nicht um die Darstellung von Zeichen, sondern um
    1.41  ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
    1.42 -Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung
    1.43 +Früher, als US-ASCII noch die omnipräsente Zeichenkodierung
    1.44  war, wurde jedes Zeichen mit genau einem
    1.45 -Byte gespeichert. Somit selektierte `cut -c' gleichermassen
    1.46 +Byte gespeichert. Somit selektierte `cut -c' gleichermaßen
    1.47  sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
    1.48  Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
    1.49 -dieser Annahme loesen. In diesem Zug bekam cut mit
    1.50 +dieser Annahme lösen. In diesem Zug bekam cut mit
    1.51  POSIX.2-1992 einen Bytemodus (Option `-b'). Will man
    1.52  also nur die ersten maximal 500 Bytes vor dem
    1.53  Newline-Zeichen stehen haben (und den Rest stillschweigend
    1.54 @@ -61,11 +61,11 @@
    1.55  	$ cut -b -500
    1.56  
    1.57  Den Rest kann man sich mit `cut -b 501-' einfangen. Diese
    1.58 -Funktion ist insbesondere fuer POSIX wichtig, da man damit
    1.59 -Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
    1.60 +Funktion ist insbesondere für POSIX wichtig, da man damit
    1.61 +Textdateien mit begrenzter Zeilenlänge erzeugen kann.
    1.62  [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
    1.63  
    1.64 -Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte
    1.65 +Wenn auch der Bytemodus neu eingeführt worden war, so sollte
    1.66  er sich doch nur so verhalten wie der alte Zeichenmodus
    1.67  normalerweise schon implementiert war. Beim Zeichenmodus aber
    1.68  wurde eine neue Implementierungsweise gefordert. Das Problem
    1.69 @@ -74,11 +74,11 @@
    1.70  
    1.71  Neben dem Zeichen- und Bytemodus bietet cut noch den
    1.72  Feldmodus, den man mit `-f' einleitet. Mit ihm
    1.73 -koennen Felder ausgewaehlt werden. Das Trennzeichen (per
    1.74 -Default der Tab) kann mit `-d' geaendert werden. Es gilt in
    1.75 -gleicher Weise fuer die Eingabe und die Ausgabe.
    1.76 +können Felder ausgewählt werden. Das Trennzeichen (per
    1.77 +Default der Tab) kann mit `-d' geändert werden. Es gilt in
    1.78 +gleicher Weise für die Eingabe und die Ausgabe.
    1.79  
    1.80 -Der typische Anwendungsfall fuer cut im Feldmodus ist die
    1.81 +Der typische Anwendungsfall für cut im Feldmodus ist die
    1.82  Auswahl von Information aus der passwd-Datei. Hier z.B. der
    1.83  Benutzername und seine ID:
    1.84  
    1.85 @@ -89,27 +89,27 @@
    1.86  	mail:8
    1.87  	...
    1.88  
    1.89 -(Die Argumente fuer die Optionen koennen bei cut uebrigens
    1.90 -mit Whitespace abgetrennt oder direkt angehaengt folgen.)
    1.91 +(Die Argumente für die Optionen können bei cut übrigens
    1.92 +mit Whitespace abgetrennt oder direkt angehängt folgen.)
    1.93  
    1.94 -Dieser Feldmodus ist fuer einfache tabellarische Dateien,
    1.95 +Dieser Feldmodus ist für einfache tabellarische Dateien,
    1.96  wie eben die passwd, gut geeignet. Er kommt aber schnell an
    1.97 -seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
    1.98 +seine Grenzen. Gerade der häufige Fall, dass an Whitespace
    1.99  in Felder geteilt werden soll, wird damit nicht abgedeckt.
   1.100  Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
   1.101  demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
   1.102  werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander
   1.103 -stehende Trennzeichen fuehren zu einem leeren Feld. Dieses
   1.104 +stehende Trennzeichen führen zu einem leeren Feld. Dieses
   1.105  Verhalten widerspricht den Erwartungen, die man an die
   1.106  Verarbeitung einer Datei mit Whitespace-getrennten Feldern
   1.107  hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
   1.108 -haben deshalb Erweiterungen, die das gewuenschte Verhalten
   1.109 -fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
   1.110 +haben deshalb Erweiterungen, die das gewünschte Verhalten
   1.111 +für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
   1.112  man portabel bleiben will, verwendet man awk in diesen
   1.113 -Faellen.
   1.114 +Fällen.
   1.115  
   1.116  Awk bietet noch eine weitere Funktion, die cut missen
   1.117 -laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
   1.118 +lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
   1.119  cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
   1.120  Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt
   1.121  der Aufruf
   1.122 @@ -121,8 +121,8 @@
   1.123  der Manpage von Version 8 Unix wiederzugeben: ``In data base
   1.124  parlance, it projects a relation.''
   1.125  [ http://man.cat-v.org/unix_8th/1/cut
   1.126 -Cut fuehrt demnach die Datenbankoperation Projektion auf
   1.127 -Textdateien aus. Die Wikipedia erklaert das folgendermassen:
   1.128 +Cut führt demnach die Datenbankoperation Projektion auf
   1.129 +Textdateien aus. Die Wikipedia erklärt das folgendermaßen:
   1.130  
   1.131  	Die Projektion entspricht der Projektionsabbildung aus der
   1.132  	Mengenlehre und kann auch Attributbeschränkung genannt
   1.133 @@ -137,28 +137,28 @@
   1.134  Geschichtliches
   1.135  
   1.136  Cut erblickte 1982 mit dem Release von UNIX System III das
   1.137 -Licht der oeffentlichen Welt. Wenn man die Quellen von System
   1.138 +Licht der öffentlichen Welt. Wenn man die Quellen von System
   1.139  III durchforstet, findet man die Quellcodedatei cut.c mit dem
   1.140  Zeitstempel 1980-04-11.
   1.141  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
   1.142 -Das ist die aelteste Manifestation des Programms, die ich
   1.143 -aufstoebern konnte. Allerdings spricht die SCCS-ID im
   1.144 +Das ist die älteste Manifestation des Programms, die ich
   1.145 +aufstöbern konnte. Allerdings spricht die SCCS-ID im
   1.146  Quellcode von Version 1.5. Die Vorgeschichte liegt, der Aussage
   1.147  Doug McIlroys
   1.148  [ XXX
   1.149 -zufolge, in PWB/UNIX, das die Grundlage fuer System III war.
   1.150 +zufolge, in PWB/UNIX, das die Grundlage für System III war.
   1.151  (PWB 3.0 entspricht System III.) In den von PWB 1.0 (1977)
   1.152 -verfuegbaren Quellen
   1.153 +verfügbaren Quellen
   1.154  [ XXX
   1.155  ist cut noch nicht zu finden; von PWB 2.0 sind mir keine
   1.156 -verfuegbaren Quellen oder hilfreiche Dokumentation bekannt.
   1.157 +verfügbaren Quellen oder hilfreiche Dokumentation bekannt.
   1.158  
   1.159 -Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester
   1.160 +Nun ein Blick auf die BSD-Linie: Dort ist mein frühester
   1.161  Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
   1.162  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
   1.163  als Teil der Spezialversion 4.3BSD-UWisc,
   1.164  [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
   1.165 -die im Januar 1987 veroeffentlicht wurde.
   1.166 +die im Januar 1987 veröffentlicht wurde.
   1.167  Die Implementierung unterscheidet sich nur minimal von der
   1.168  in System III.
   1.169  Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
   1.170 @@ -169,12 +169,12 @@
   1.171  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
   1.172  Seine Manpage
   1.173  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
   1.174 -erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
   1.175 +erwähnt bereits die erwartete Konformität mit POSIX.2.
   1.176  Nun muss man wissen, dass POSIX.2 erst im September
   1.177 -1992 veroeffentlicht wurde, erst gut zwei Jahren nachdem die
   1.178 +1992 veröffentlicht wurde, erst gut zwei Jahren nachdem die
   1.179  Manpage und das Programm geschrieben worden waren. Das Programm
   1.180  wurde folglich anhand von Arbeitsversionen des Standards
   1.181 -implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
   1.182 +implementiert. Ein Blick in den Code bekräftigt diese Vermutung.
   1.183  In der Funktion zum parsen der Feldauswahlliste findet sich
   1.184  dieser Kommentar:
   1.185  
   1.186 @@ -182,61 +182,61 @@
   1.187  	POSIX doesn't allow lists that aren't in increasing order or
   1.188  	overlapping lists.
   1.189  
   1.190 -Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits
   1.191 +Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits
   1.192  ein:
   1.193  
   1.194  	The elements in list can be repeated, can overlap, and can
   1.195  	be specified in any order.
   1.196  
   1.197 -Zudem listet Draft 11.2 alle drei Modi, waehrend in diesem
   1.198 -BSD cut nur die zwei alten implementiert sind. Es koennte also
   1.199 +Zudem listet Draft 11.2 alle drei Modi, während in diesem
   1.200 +BSD cut nur die zwei alten implementiert sind. Es könnte also
   1.201  sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
   1.202  Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
   1.203 -leider nicht moeglich, diese Vermutung zu pruefen.
   1.204 +leider nicht möglich, diese Vermutung zu prüfen.
   1.205  
   1.206 -Die Versionsnummern und Aenderungsdaten der aelteren
   1.207 +Die Versionsnummern und Änderungsdaten der älteren
   1.208  BSD-Implementierungen kann man aus den SCCS-IDs, die vom
   1.209 -damaligen Versionskontrollsystem in den Code eingefuegt wurden,
   1.210 +damaligen Versionskontrollsystem in den Code eingefügt wurden,
   1.211  ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
   1.212  
   1.213 -Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
   1.214 +Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:
   1.215  
   1.216  	Copyright (C) 1997-2015 Free Software Foundation, Inc.
   1.217  	Copyright (C) 1984 David M. Ihnat
   1.218  
   1.219 -Der Code hat also recht alte Urspruenge. Wie aus weiteren
   1.220 +Der Code hat also recht alte Ursprünge. Wie aus weiteren
   1.221  Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
   1.222 -MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
   1.223 +MacKenzie und später von Jim Meyering überarbeitet. Letzterer
   1.224  hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
   1.225  Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
   1.226  Copyright-Vermerk auftauchen, ist unklar.
   1.227  
   1.228 -Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
   1.229 -aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
   1.230 -Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
   1.231 -so war Unix doch schon ueber zehn Jahre alt, als cut das
   1.232 -erste Mal auftauchte. Insbesondere gehoerte cut noch nicht
   1.233 +Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut,
   1.234 +aus Sicht des ursprünglichen Unix, zu den jüngeren Tools.
   1.235 +Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist,
   1.236 +so war Unix doch schon über zehn Jahre alt, als cut das
   1.237 +erste Mal auftauchte. Insbesondere gehörte cut noch nicht
   1.238  zu Version 7 Unix, das die Ausgangsbasis aller modernen
   1.239  Unix-Systeme darstellt. Die weit komplexeren Programme sed
   1.240  und awk waren dort schon vertreten. Man muss sich also
   1.241 -fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
   1.242 +fragen, warum cut überhaupt noch entwickelt wurde, wo es
   1.243  schon zwei Programme gab, die die Funktion von cut abdecken
   1.244 -konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
   1.245 -die damit verbundene Geschwindigkeit gegenueber dem damals
   1.246 -traegen awk. Diese schlanke Gestalt ist es auch, die der
   1.247 +konnten. Ein Argument für cut war sicher seine Kompaktheit und
   1.248 +die damit verbundene Geschwindigkeit gegenüber dem damals
   1.249 +trägen awk. Diese schlanke Gestalt ist es auch, die der
   1.250  Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
   1.251 -Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
   1.252 -standardisiert und ist heutzutage ueberall anzutreffen.
   1.253 +Cut überzeugte. Es wurde in andere Unix Varianten übernommen,
   1.254 +standardisiert und ist heutzutage überall anzutreffen.
   1.255  
   1.256 -Die urspruengliche Variante (ohne -b) wurde schon 1985 in
   1.257 +Die ursprüngliche Variante (ohne -b) wurde schon 1985 in
   1.258  der System V Interface Definition, einer wichtigen formalen
   1.259  Beschreibung von UNIX System V, spezifiziert und tauchte
   1.260 -anschliessend in allen relevanten Standards auf. Mit POSIX.2
   1.261 +anschließend in allen relevanten Standards auf. Mit POSIX.2
   1.262  im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
   1.263  (mit -b) standardisiert.
   1.264  
   1.265  
   1.266 -Multibyte-Unterstuetzung
   1.267 +Multibyte-Unterstützung
   1.268  
   1.269  Nun sind der Bytemodus und die damit verbundene
   1.270  Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
   1.271 @@ -245,11 +245,11 @@
   1.272  Die Situation ist dreiteilig: Es gibt historische
   1.273  Implementierungen, die nur -c und -f kennen. Dann gibt es
   1.274  Implementierungen die -b zwar kennen, es aber lediglich als Alias
   1.275 -fuer -c handhaben. Diese Implementierungen funktionieren mit
   1.276 +für -c handhaben. Diese Implementierungen funktionieren mit
   1.277  Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
   1.278 -Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
   1.279 -wie -b (und -n wird ignoriert). Schliesslich gibt es noch
   1.280 -Implementierungen, die -b und -c tatsaechlich POSIX-konform
   1.281 +Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber
   1.282 +wie -b (und -n wird ignoriert). Schließlich gibt es noch
   1.283 +Implementierungen, die -b und -c tatsächlich POSIX-konform
   1.284  implementieren.
   1.285  
   1.286  Historische Zwei-Modi-Implementierungen sind z.B. die von
   1.287 @@ -257,11 +257,11 @@
   1.288  
   1.289  Pseudo-Multibyte-Implementierungen bieten GNU und die
   1.290  modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
   1.291 -ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
   1.292 +ob dort ein Schein von POSIX-Konformität gewahrt wird.
   1.293  Teilweise findet man erst nach genauerer Suche heraus, dass
   1.294  -c und -n nicht wie erwartet funktionieren; teilweise machen es
   1.295  sich die Systeme auch einfach, indem sie auf
   1.296 -Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
   1.297 +Singlebyte-Zeichenkodierungen beharren, das aber dafür meist
   1.298  klar darlegen:
   1.299  
   1.300  	Since we don't support multi-byte characters, the -c and -b
   1.301 @@ -269,20 +269,20 @@
   1.302  
   1.303  [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
   1.304  
   1.305 -Tatsaechlich standardkonforme Implementierungen, die
   1.306 +Tatsächlich standardkonforme Implementierungen, die
   1.307  Multibytes korrekt handhaben, bekommt man bei einem modernen
   1.308  FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
   1.309  im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
   1.310  [ https://svnweb.freebsd.org/base?view=revision&revision=131194
   1.311 -Warum die beiden anderen grossen BSDs diese Aenderung nicht
   1.312 -uebernommen haben, bleibt offen. Es scheint aber an der im
   1.313 +Warum die beiden anderen großen BSDs diese Änderung nicht
   1.314 +übernommen haben, bleibt offen. Es scheint aber an der im
   1.315  obigen Kommentar formulierten Grundausrichtung zu liegen.
   1.316  
   1.317  Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
   1.318 -Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
   1.319 +Systems Multibytes korrekt unterstützt werden? Zuerst ist
   1.320  entscheidend, ob das System selbst mit einem Multibyte-Encoding
   1.321  arbeitet, denn tut es das nicht, dann entsprechen sich
   1.322 -Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
   1.323 +Zeichen und Bytes und die Frage erübrigt sich. Man kann das
   1.324  herausfinden indem man sich das Locale anschaut, aber einfacher
   1.325  ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
   1.326  auszugeben und zu schauen ob dieses in einem oder in mehreren
   1.327 @@ -293,7 +293,7 @@
   1.328  	0000003
   1.329  
   1.330  In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
   1.331 -Zeilenumbruch fuegt echo(1) hinzu.)
   1.332 +Zeilenumbruch fügt echo(1) hinzu.)
   1.333  
   1.334  Mit dem Programm iconv(1) kann man Text explizit in bestimmte
   1.335  Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
   1.336 @@ -311,7 +311,7 @@
   1.337  wird recht sicher einer dieser beiden Ausgaben entsprechen.
   1.338  
   1.339  Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
   1.340 -dann sollte sich eine POSIX-konforme Implementierung folgendermassen
   1.341 +dann sollte sich eine POSIX-konforme Implementierung folgendermaßen
   1.342  verhalten:
   1.343  
   1.344  	$ echo ä | cut -c 1 | od -c
   1.345 @@ -327,7 +327,7 @@
   1.346  	0000001
   1.347  
   1.348  Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
   1.349 -allen drei Faellen wie die mittlere: Es wird das erste Byte
   1.350 +allen drei Fällen wie die mittlere: Es wird das erste Byte
   1.351  ausgegeben.
   1.352  
   1.353  
   1.354 @@ -336,15 +336,15 @@
   1.355  Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
   1.356  Implementierungen.
   1.357  
   1.358 -Fuer einen ersten Eindruck ist der Umfang des Quellcodes
   1.359 -hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
   1.360 +Für einen ersten Eindruck ist der Umfang des Quellcodes
   1.361 +hilfreich. Typischerweise steigt dieser über die Jahre an. Diese
   1.362  Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
   1.363 -bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
   1.364 -erfordert zwangslaeufig mehr Code, deshalb sind diese
   1.365 +bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
   1.366 +erfordert zwangsläufig mehr Code, deshalb sind diese
   1.367  Implementierungen tendenziell umfangreicher.
   1.368  
   1.369  
   1.370 -	SLOC	Zeilen	Bytes	Gehoert zu  	Dateidatum	Kategorie
   1.371 +	SLOC	Zeilen	Bytes	Gehört zu  	Dateidatum	Kategorie
   1.372  	-----------------------------------------------------------------
   1.373  	116	123	 2966	System III	1980-04-11	(hist)
   1.374  	118	125	 3038	4.3BSD-UWisc	1986-11-07	(hist)
   1.375 @@ -360,56 +360,60 @@
   1.376  
   1.377  
   1.378  Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
   1.379 -urspruenglichen Implementierungen, die sich nur minimal
   1.380 -unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
   1.381 +ursprünglichen Implementierungen, die sich nur minimal
   1.382 +unterscheiden, mit gut 100 SLOCs. (2) Die fünf BSD-Versionen mit
   1.383  gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
   1.384 -die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
   1.385 +die alte GNU-Version mit 340-390 SLOCs. Und schließlich (4) die
   1.386  moderne GNU-Variante mit fast 600 SLOCs.
   1.387  
   1.388  Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
   1.389 -SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
   1.390 --l') erstreckt sich ueber eine Spanne von Faktor 1.06 bei den
   1.391 -aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Den groessten
   1.392 +SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (`wc
   1.393 +-l') erstreckt sich über eine Spanne von Faktor 1.06 bei den
   1.394 +ältesten Vertretern bis zu Faktor 1.5 bei GNU. Den größten
   1.395  Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und
   1.396 -die Groesse des Lizenzblocks am Dateianfang. 
   1.397 +die Größe des Lizenzblocks am Dateianfang. 
   1.398  
   1.399  Betrachtet man die Abweichungen zwischen den logischen Codezeilen
   1.400 -und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
   1.401 +und der Dateigröße (`wc -c'), so pendelt das Teilnehmerfeld
   1.402  zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
   1.403  weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
   1.404 -fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren
   1.405 -Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
   1.406 -Ob man die Heirloom-Implementierung als besonders kryptisch
   1.407 +fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren
   1.408 +Programmierstil, mit spezieller Einrückung und langen Bezeichnern.
   1.409 +Ob man die Heirloom-Implementierung
   1.410 +[ XXX
   1.411 +als besonders kryptisch
   1.412  oder als besonders elegant bezeichnen will, das soll der
   1.413 -eigenen Einschaetzung des Lesers ueberlassen bleiben. Vor allem
   1.414 -der Vergleich mit einer GNU-Implementierung ist eindrucksvoll.
   1.415 +eigenen Einschätzung des Lesers überlassen bleiben. Vor allem
   1.416 +der Vergleich mit einer GNU-Implementierung
   1.417 +[ XXX
   1.418 +ist eindrucksvoll.
   1.419  
   1.420  
   1.421 -Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
   1.422 +Die interne Struktur der Programmcodes (in C) ist meist ähnlich.
   1.423  Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
   1.424  verarbeitet, gibt es im Normalfall eine Funktion, die die
   1.425 -Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
   1.426 -haben fast alle Implementierungen separate Funktionen fuer die
   1.427 +Feldauswahl in eine interne Datenstruktur überführt. Desweiteren
   1.428 +haben fast alle Implementierungen separate Funktionen für die
   1.429  zwei oder drei Modi. Bei den POSIX-konformen Implementierungen
   1.430  wird die `-b -n'-Kombination als weiterer Modus behandelt, und
   1.431 -damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
   1.432 +damit in einer eigenen Funktion umgesetzt. Nur bei der frühen
   1.433  System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
   1.434 -wird ausser den Fehlerausgaben alles in der main-Funktion
   1.435 +wird außer den Fehlerausgaben alles in der main-Funktion
   1.436  erledigt.
   1.437  
   1.438  Cut-Implementierungen haben typischerweise zwei limitierende
   1.439 -Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
   1.440 -Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt.
   1.441 +Größen: Die Maximalanzahl unterstützter Felder und die maximale
   1.442 +Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt.
   1.443  4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
   1.444  Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
   1.445  FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
   1.446  Heirloom kann sowohl die Felderanzahl als auch die maximale
   1.447 -Zeilenlaenge beliebig gross werden; der Speicher dafuer wird
   1.448 +Zeilenlänge beliebig groß werden; der Speicher dafür wird
   1.449  dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
   1.450 -Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
   1.451 +Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die
   1.452  begrenzte Felderanzahl scheint jedoch kein Praxisproblem
   1.453  darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
   1.454 -gross genug sein sollte.
   1.455 +groß genug sein sollte.
   1.456  
   1.457  
   1.458  Beschreibungen
   1.459 @@ -448,44 +452,44 @@
   1.460  
   1.461  
   1.462  Die mit ``(src)'' markierten Beschreibungen sind aus dem
   1.463 -jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
   1.464 +jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält
   1.465  die Beschreibung im Standard. Der ``Unix Reader'' ist ein
   1.466 -rueckblickendes Textdokument von Doug McIlroy, das das
   1.467 +rückblickendes Textdokument von Doug McIlroy, das das
   1.468  Auftreten der Tools in der Geschichte des Research Unix zum
   1.469  Thema hat.
   1.470  [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
   1.471  Eigentlich sollte seine Beschreibung der in Version 8 Unix
   1.472 -entsprechen. Die Abweichung koennte ein Uebertragungsfehler
   1.473 -oder eine nachtraegliche Korrektur sein. Alle uebrigen
   1.474 +entsprechen. Die Abweichung könnte ein Übertragungsfehler
   1.475 +oder eine nachträgliche Korrektur sein. Alle übrigen
   1.476  Beschreibungen entstammen den Manpages.
   1.477  
   1.478 -Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
   1.479 +Oft ist mit der Zeit die POSIX-Beschreibung übernommen
   1.480  oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
   1.481  [ https://svnweb.freebsd.org/base?view=revision&revision=167101
   1.482  
   1.483  Interessant ist, dass die GNU coreutils seit Anbeginn vom
   1.484  Entfernen von Teilen der Eingabe sprechen, wohingegen die
   1.485 -Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
   1.486 -Worte ``cut out'' sind vielleicht auch zu missverstaendlich.
   1.487 -HP-UX hat sie deshalb praezisiert.
   1.488 +Kommandozeilenangabe klar ein Auswählen darstellt. Die
   1.489 +Worte ``cut out'' sind vielleicht auch zu missverständlich.
   1.490 +HP-UX hat sie deshalb präzisiert.
   1.491  
   1.492  Beim Begriff, was selektiert wird, ist man sich ebenfalls
   1.493  uneins. Die Einen reden von Feldern (POSIX), Andere von
   1.494  Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
   1.495  (Research Unix). Ironischerweise leistet sich gerade Version
   1.496  8 Unix, das eigentlich um eine sehr treffende Weltsicht
   1.497 -bemueht ist, mit ``rearrange columns of data'' die
   1.498 +bemüht ist, mit ``rearrange columns of data'' die
   1.499  unzutreffendste der Beschreibungen.
   1.500  
   1.501  
   1.502  Autoreninfo
   1.503  
   1.504 -Markus Schnalke interessiert sich fuer die Hintergruende
   1.505 -von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses
   1.506 +Markus Schnalke interessiert sich für die Hintergründe
   1.507 +von Unix und seinen Werkzeugen. Für die Erarbeitung dieses
   1.508  Textes wurde er regelrecht zum Historiker.
   1.509  
   1.510  
   1.511  Lizenz
   1.512  
   1.513  CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
   1.514 -veroeffentlicht werden)
   1.515 +veröffentlicht werden)