1.1 --- a/cut.txt	Tue May 12 22:49:21 2015 +0200
     1.2 +++ b/cut.txt	Wed May 13 07:18:16 2015 +0200
     1.3 @@ -47,8 +47,8 @@
     1.4  
     1.5  Geht es aber nicht um die Darstellung von Zeichen, sondern um
     1.6  ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
     1.7 -Frueher, als US-ASCII als Zeichensatz und -kodierung
     1.8 -noch omnipraesent war, wurde jedes Zeichen mit genau einem
     1.9 +Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung
    1.10 +war, wurde jedes Zeichen mit genau einem
    1.11  Byte gespeichert. Somit selektierte `cut -c' gleichermassen
    1.12  sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
    1.13  Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
    1.14 @@ -65,45 +65,45 @@
    1.15  Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
    1.16  [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
    1.17  
    1.18 -Auch wenn der Bytemodus neu eingefuehrt wurde, so sollte er
    1.19 -sich doch nur so verhalten wie der alte Zeichenmodus normalerweise
    1.20 -implementiert war. Beim Zeichenmodus aber wurde durch POSIX.2
    1.21 -eine andere Implementierungsweise gefordert. Das Problem war
    1.22 -also nicht, den neuen Bytemodus zu implementieren, sondern
    1.23 +Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte
    1.24 +er sich doch nur so verhalten wie der alte Zeichenmodus
    1.25 +normalerweise schon implementiert war. Beim Zeichenmodus aber
    1.26 +wurde eine neue Implementierungsweise gefordert. Das Problem
    1.27 +war also nicht, den neuen Bytemodus zu implementieren, sondern
    1.28  den Zeichenmodus neu zu implementieren.
    1.29  
    1.30 -Neben dem Zeichen- und Byte-Modus bietet cut noch den
    1.31 -Feld-Modus, den man mit `-f' einleitet. Mit ihm
    1.32 +Neben dem Zeichen- und Bytemodus bietet cut noch den
    1.33 +Feldmodus, den man mit `-f' einleitet. Mit ihm
    1.34  koennen Felder ausgewaehlt werden. Das Trennzeichen (per
    1.35  Default der Tab) kann mit `-d' geaendert werden.
    1.36  
    1.37 -Der typische Anwendungsfall fuer cut im Feld-Modus ist die
    1.38 +Der typische Anwendungsfall fuer cut im Feldmodus ist die
    1.39  Auswahl von Information aus der passwd-Datei. So z.B. der
    1.40 -Benutzername, seine ID und das Homeverzeichnis:
    1.41 +Benutzername und seine ID:
    1.42  
    1.43 -	$ cut -d: -f1,3,6 /etc/passwd
    1.44 -	root:0:/root
    1.45 -	bin:1:/bin
    1.46 -	daemon:2:/sbin
    1.47 -	mail:8:/var/spool/mail
    1.48 +	$ cut -d: -f1,3 /etc/passwd
    1.49 +	root:0
    1.50 +	bin:1
    1.51 +	daemon:2
    1.52 +	mail:8
    1.53  	...
    1.54  
    1.55  (Die Argumente fuer die Optionen koennen bei cut uebrigens
    1.56  mit Whitespace abgetrennt oder direkt angehaengt folgen.)
    1.57  
    1.58 -Dieser Feld-Modus ist fuer einfache tabellarische Dateien,
    1.59 +Dieser Feldmodus ist fuer einfache tabellarische Dateien,
    1.60  wie eben die passwd, gut geeignet. Er kommt aber schnell an
    1.61  seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
    1.62  in Felder geteilt werden soll, wird damit nicht abgedeckt.
    1.63 -Der Delimiter kann nur genau ein Zeichen sein. Es kann also
    1.64 -nicht sowohl an Leerzeichen als auch an Tabs getrennt werden.
    1.65 -Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
    1.66 +Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
    1.67 +also nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
    1.68 +werden. Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
    1.69  stehende Trennzeichen fuehren zu einem leeren Feld. Dieses
    1.70  Verhalten widerspricht den Erwartungen, die man an die
    1.71  Verarbeitung einer Datei mit Whitespace-getrennten Feldern
    1.72  hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
    1.73 -haben aber Erweiterungen, die das gewuenschte Verhalten fuer
    1.74 -Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
    1.75 +haben deshalb Erweiterungen, die das gewuenschte Verhalten
    1.76 +fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
    1.77  man portabel bleiben will, verwendet man awk in diesen
    1.78  Faellen.
    1.79  
    1.80 @@ -140,34 +140,32 @@
    1.81  Zeitstempel 1980-04-11.
    1.82  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
    1.83  Das ist die aelteste Manifestation des Programms, die ich
    1.84 -aufstoebern konnte. Allerdings spricht die sccsid im
    1.85 +aufstoebern konnte. Allerdings spricht die SCCS-ID im
    1.86  Quellcode von Version 1.5. Es muss also noch eine
    1.87  Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
    1.88  gefunden.
    1.89  XXX mail an TUHS
    1.90  
    1.91 -Nun ein Blick auf die BSD-Linie: Dort ist mein
    1.92 -fruehester Fund ein cut.c mit dem Dateimodifikationsdatum
    1.93 -1986-11-07
    1.94 +Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester
    1.95 +Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
    1.96  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
    1.97  als Teil der Spezialversion 4.3BSD-UWisc,
    1.98  [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
    1.99  die im Januar 1987 veroeffentlicht wurde.
   1.100  Die Implementierung unterscheidet sich nur minimal von der
   1.101  in System III.
   1.102 -Im bekannteren 4.3BSD-Tahoe (1988) taucht cut nicht auf.
   1.103 -Das darauf folgende 4.3BSD-Reno (1990) liefert aber wieder
   1.104 -ein cut mit aus. Dieses cut ist ein von Adam S. Moskowitz und
   1.105 +Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
   1.106 +Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
   1.107 +ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
   1.108  Marciano Pitargue neu implementiertes cut, das 1989 in BSD
   1.109  aufgenommen wurde.
   1.110  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
   1.111  Seine Manpage
   1.112  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
   1.113  erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
   1.114 -XXX 2 oder 3 modi? Draft 9: 2 modi?  Draft 11.2 hat 3 modi!
   1.115 -Nun sollte man wissen, dass POSIX.2 erst im September
   1.116 +Nun muss man wissen, dass POSIX.2 erst im September
   1.117  1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
   1.118 -Manpage und das Programm geschrieben wurden. Das Programm
   1.119 +Manpage und das Programm geschrieben worden waren. Das Programm
   1.120  wurde folglich anhand von Arbeitsversionen des Standards
   1.121  implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
   1.122  In der Funktion zum parsen der Feldauswahlliste findet sich
   1.123 @@ -183,9 +181,15 @@
   1.124  	The elements in list can be repeated, can overlap, and can
   1.125  	be specified in any order.
   1.126  
   1.127 -Die Versionsnummern und Aenderungsdatums der aelteren
   1.128 -BSD-Implementierungen kann man aus den SCCS-IDs (die vom
   1.129 -damaligen Versionskontrollsystem in den Code eingefuegt wurden)
   1.130 +Auch listet Draft 11.2 alle drei Modi, waehrend in diesem
   1.131 +BSD cut nur die zwei alten implementiert sind. Es koennte also
   1.132 +sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
   1.133 +Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
   1.134 +leider nicht moeglich, diese Vermutung zu pruefen. XXX
   1.135 +
   1.136 +Die Versionsnummern und Aenderungsdaten der aelteren
   1.137 +BSD-Implementierungen kann man aus den SCCS-IDs, die vom
   1.138 +damaligen Versionskontrollsystem in den Code eingefuegt wurden,
   1.139  ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
   1.140  
   1.141  Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
   1.142 @@ -193,12 +197,12 @@
   1.143  	Copyright (C) 1997-2015 Free Software Foundation, Inc.
   1.144  	Copyright (C) 1984 David M. Ihnat
   1.145  
   1.146 -Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren
   1.147 -Kommentaren zu entnehmen ist, wurde der Code zuerst von David
   1.148 +Der Code hat also recht alte Urspruenge. Wie aus weiteren
   1.149 +Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
   1.150  MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
   1.151  hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
   1.152 -Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk
   1.153 -auftauchen, ist unklar.
   1.154 +Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
   1.155 +Copyright-Vermerk auftauchen, ist unklar.
   1.156  
   1.157  Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
   1.158  aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
   1.159 @@ -212,8 +216,8 @@
   1.160  schon zwei Programme gab, die die Funktion von cut abdecken
   1.161  konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
   1.162  die damit verbundene Geschwindigkeit gegenueber dem damals
   1.163 -traegen awk. Diese schlanke Gestalt ist es auch, die der Unix
   1.164 -Philosopie entspricht: Mache eine Aufgabe und die richtig!
   1.165 +traegen awk. Diese schlanke Gestalt ist es auch, die der
   1.166 +Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
   1.167  Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
   1.168  standardisiert und ist heutzutage ueberall anzutreffen.
   1.169  
   1.170 @@ -232,27 +236,27 @@
   1.171  Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
   1.172  1992 standardisiert, wie steht es aber mit deren Umsetzung?
   1.173  Welche Versionen implementieren POSIX korrekt?
   1.174 -Die Situation ist dreiteilig: Es gibt traditionelle
   1.175 +Die Situation ist dreiteilig: Es gibt historische
   1.176  Implementierungen, die nur -c und -f kennen. Dann gibt es
   1.177  Implementierungen die -b zwar kennen, es aber lediglich als Alias
   1.178  fuer -c handhaben. Diese Implementierungen funktionieren mit
   1.179  Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
   1.180 -Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
   1.181 +Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
   1.182  wie -b (und -n wird ignoriert). Schliesslich gibt es noch
   1.183  Implementierungen, die -b und -c tatsaechlich POSIX-konform
   1.184  implementieren.
   1.185  
   1.186 -Traditionelle Zwei-Modi-Implementierungen sind z.B. die von
   1.187 +Historische Zwei-Modi-Implementierungen sind z.B. die von
   1.188  System III, System V und die aller BSDs bis in die 90er.
   1.189  
   1.190  Pseudo-Multibyte-Implementierungen bieten GNU und die
   1.191 -modernen NetBSDs und OpenBSDs. Man darf sich durchaus fragen,
   1.192 +modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
   1.193  ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
   1.194  Teilweise findet man erst nach genauerer Suche heraus, dass
   1.195  -c und -n nicht wie erwartet funktionieren; teilweise machen es
   1.196 -sich die System auch einfach, indem sie auf
   1.197 -Singlebyte-Zeichenkodierungen beharren, das aber dafuer klar
   1.198 -darlegen:
   1.199 +sich die Systeme auch einfach, indem sie auf
   1.200 +Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
   1.201 +klar darlegen:
   1.202  
   1.203  	Since we don't support multi-byte characters, the -c and -b
   1.204  	options are equivalent, and the -n option is meaningless.
   1.205 @@ -268,10 +272,10 @@
   1.206  uebernommen haben, bleibt offen. Es scheint aber an der im
   1.207  obigen Kommentar formulierten Grundausrichtung zu liegen.
   1.208  
   1.209 -Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen
   1.210 +Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
   1.211  Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
   1.212  entscheidend, ob das System selbst mit einem Multibyte-Encoding
   1.213 -arbeitet, denn tut es das nicht, dann entsprechen sich naemlich
   1.214 +arbeitet, denn tut es das nicht, dann entsprechen sich
   1.215  Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
   1.216  herausfinden indem man sich das Locale anschaut, aber einfacher
   1.217  ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
   1.218 @@ -301,7 +305,8 @@
   1.219  wird recht sicher einer dieser beiden Ausgaben entsprechen.
   1.220  
   1.221  Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
   1.222 -dann sollte sich eine POSIX-konforme Implementierung so verhalten:
   1.223 +dann sollte sich eine POSIX-konforme Implementierung folgendermassen
   1.224 +verhalten:
   1.225  
   1.226  	$ echo ä | ./cut -c 1 | od -c
   1.227  	0000000 303 244  \n
   1.228 @@ -328,19 +333,19 @@
   1.229  Fuer einen ersten Eindruck ist der Umfang des Quellcodes
   1.230  hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
   1.231  Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
   1.232 -bestaetigt werden. Die Unterstuetzung des Byte-Modus (-b)
   1.233 -erfordert zwangslaeufig mehr Code, deshalb sind die
   1.234 -POSIX-konformen Implementierungen tendenziell umfangreicher.
   1.235 +bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
   1.236 +erfordert zwangslaeufig mehr Code, deshalb sind diese
   1.237 +Implementierungen tendenziell umfangreicher.
   1.238  
   1.239  
   1.240  	SLOC	Zeilen	Bytes	Gehoert zu  	Dateidatum	Kategorie
   1.241  	-----------------------------------------------------------------
   1.242 -	116	123	 2966	System III	1980-04-11	(trad)
   1.243 -	118	125	 3038	4.3BSD-UWisc	1986-11-07	(trad)
   1.244 -	200	256	 5715	4.3BSD-Reno	1990-06-25	(trad)
   1.245 -	200	270	 6545	NetBSD	 	1993-03-21	(trad)
   1.246 +	116	123	 2966	System III	1980-04-11	(hist)
   1.247 +	118	125	 3038	4.3BSD-UWisc	1986-11-07	(hist)
   1.248 +	200	256	 5715	4.3BSD-Reno	1990-06-25	(hist)
   1.249 +	200	270	 6545	NetBSD	 	1993-03-21	(hist)
   1.250  	218	290	 6892	OpenBSD		2008-06-27	(pseudo)
   1.251 -	224	296	 6920	FreeBSD		1994-05-27	(trad)
   1.252 +	224	296	 6920	FreeBSD		1994-05-27	(hist)
   1.253  	232	306	 7500	NetBSD 		2014-02-03	(pseudo)
   1.254  	340	405	 7423	Heirloom	2012-05-20	(POSIX)
   1.255  	382	586	14175	GNU coreutils	1992-11-08	(pseudo)
   1.256 @@ -352,8 +357,8 @@
   1.257  urspruenglichen Implementierungen, die sich nur minimal
   1.258  unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
   1.259  gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
   1.260 -die alte GNU-Version mit 340-390 SLOCs. Und (4) die moderne
   1.261 -GNU-Variante mit fast 600 SLOCs.
   1.262 +die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
   1.263 +moderne GNU-Variante mit fast 600 SLOCs.
   1.264  
   1.265  Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
   1.266  SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
   1.267 @@ -366,15 +371,15 @@
   1.268  und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
   1.269  zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
   1.270  weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
   1.271 -fast 40 nach oben. Dies liegt bei GNU hauptsaechlich an deren
   1.272 +fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren
   1.273  Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
   1.274  Ob man die Heirloom-Implementierung als besonders kryptisch
   1.275  oder als besonders elegant bezeichnen will, das soll der
   1.276  eigenen Einschaetzung des Lesers ueberlassen bleiben.
   1.277  
   1.278  
   1.279 -Die interne Struktur des C-Codes ist meist aehnlich. Neben der
   1.280 -obligatorischen main-Funktion, die die Kommandozeilenargumente
   1.281 +Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
   1.282 +Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
   1.283  verarbeitet, gibt es im Normalfall eine Funktion, die die
   1.284  Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
   1.285  haben fast alle Implementierungen separate Funktionen fuer die
   1.286 @@ -382,28 +387,28 @@
   1.287  wird die `-b -n'-Kombination als weiterer Modus behandelt, und
   1.288  damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
   1.289  System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
   1.290 -wird ausser den Fehlerausgaben nichts aus der main-Funktion
   1.291 -ausgelagert.
   1.292 +wird ausser den Fehlerausgaben alles in der main-Funktion
   1.293 +erledigt.
   1.294  
   1.295  Cut-Implementierungen haben typischerweise zwei limitierende
   1.296  Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
   1.297 -Zeilenlaenge. Bei System III ist die Anzahl der moeglichen Felder
   1.298 -und ebenso die Zeilenlaenge auf 512 begrenzt. 4.3BSD-Reno und die
   1.299 -BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX
   1.300 -bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei
   1.301 -allen GNU-Implementierungen und bei Heirloom kann sowohl
   1.302 -die Felderanzahl als auch die maximale Zeilenlaenge beliebig
   1.303 -gross werden; der Speicher dafür wird dynamisch alloziiert.
   1.304 -OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber
   1.305 -beliebiger Zeilenlaenge. Die begrenzte Felderanzahl scheint
   1.306 -jedoch kein praktisches Problem darzustellen, da _POSIX2_LINE_MAX
   1.307 -mit mindestens 2048 durchaus genug Platz bieten sollte.
   1.308 +Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt.
   1.309 +4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
   1.310 +Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
   1.311 +FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
   1.312 +Heirloom kann sowohl die Felderanzahl als auch die maximale
   1.313 +Zeilenlaenge beliebig gross werden; der Speicher dafür wird
   1.314 +dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
   1.315 +Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
   1.316 +begrenzte Felderanzahl scheint jedoch kein Praxisproblem
   1.317 +darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
   1.318 +gross genug sein sollte.
   1.319  
   1.320  
   1.321  Beschreibungen
   1.322  
   1.323  Interessant ist auch ein Vergleich der Kurzbeschreibungen von
   1.324 -cut, wie sie sich in der Titelzeile von Manpages oder manchmal
   1.325 +cut, wie sie sich in der Titelzeile der Manpages oder manchmal
   1.326  auch am Anfang der Quellcodedatei finden. Die folgende Liste
   1.327  ist grob zeitlich geordnet und nach Abstammung gruppiert:
   1.328  
   1.329 @@ -436,32 +441,30 @@
   1.330  
   1.331  
   1.332  Die mit ``(src)'' markierten Beschreibungen sind aus dem
   1.333 -jeweiligen Quellcode entnommen.
   1.334 -Der POSIX-Eintrag enthaelt die Beschreibung des Standards.
   1.335 -Der ``Unix Reader'' ist ein rueckblickendes Textdokument von
   1.336 -Doug McIlroy, das das Auftreten von Tools in der Geschichte
   1.337 -des Research Unix zum Thema hat.
   1.338 +jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
   1.339 +die Beschreibung des Standards. Der ``Unix Reader'' ist ein
   1.340 +rueckblickendes Textdokument von Doug McIlroy, das das
   1.341 +Auftreten von Tools in der Geschichte des Research Unix zum
   1.342 +Thema hat.
   1.343  [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
   1.344 -Eigentlich sollte seine
   1.345 -Beschreibung der in Version 8 Unix entsprechen. Die
   1.346 -Abweichung koennte sowohl ein Uebertragungsfehler als auch
   1.347 -eine nachtraegliche Korrektur sein.
   1.348 -Alle uebrigen Beschreibungen entstammen den Manpages.
   1.349 +Eigentlich sollte seine Beschreibung der in Version 8 Unix
   1.350 +entsprechen. Die Abweichung koennte sowohl ein
   1.351 +Uebertragungsfehler als auch eine nachtraegliche Korrektur
   1.352 +sein. Alle uebrigen Beschreibungen entstammen den Manpages.
   1.353  
   1.354  Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
   1.355 -oder zumindest an sie angeglichen worden, wie beispielsweise
   1.356 -bei FreeBSD.
   1.357 +oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
   1.358  [ https://svnweb.freebsd.org/base?view=revision&revision=167101
   1.359  
   1.360  Interessant ist, dass die GNU coreutils seit Anbeginn vom
   1.361  Entfernen von Teilen der Eingabe sprechen, wohingegen die
   1.362  Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
   1.363 -Worte ``cut out'' sind vielleicht auch nur etwas zu
   1.364 +Worte ``cut out'' sind vielleicht auch etwas zu
   1.365  missverstaendlich. HP-UX hat sie deshalb praezisiert.
   1.366  
   1.367  Auch beim Begriff, was selektiert wird, ist man sich
   1.368 -uneins. Die einen reden von Feldern (POSIX), andere von
   1.369 -Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten
   1.370 +uneins. Die Einen reden von Feldern (POSIX), Andere von
   1.371 +Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
   1.372  (Research Unix). Ironischerweise leistet sich gerade Version
   1.373  8 Unix, das eigentlich um eine sehr treffende Weltsicht
   1.374  bemueht ist, mit ``rearrange columns of data'' die