--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/cut.de.ms	Sun Jul 12 09:51:48 2015 +0200
@@ -0,0 +1,517 @@
+.so macros
+.lc_ctype de_DE.utf8
+
+.TL
+Cut out selected fields of each line of a file
+.AU
+markus schnalke <meillo@marmaro.de>
+..
+.FS
+2015-05.
+Dieser Text steht unter CC0.
+Er ist online verfügbar:
+.I http://marmaro.de/docs/
+.FE
+
+.LP
+Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
+In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
+es, denn es ist ein schönes, praktisches und anschauliches
+Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
+werden.
+.SH
+Funktionsweise
+.LP
+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.
+.PP
+Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
+zerteilen. Man kann damit beispielsweise bestimmte
+Zugriffsrechte aus der Ausgabe von \f(CWls -l\fP ausschneiden, in
+diesem Beispiel die Rechte des Besitzers:
+.CS
+	$ ls -l foo
+	-rw-rw-r-- 1 meillo users 0 May 12 07:32 foo
+.sp .3
+	$ ls -l foo | cut -c 2-4
+	rw-
+.CE
+.LP
+Oder die Schreibrechte des Besitzers, der Gruppe und der
+Welt:
+.CS
+	$ ls -l foo | cut -c 3,6,9
+	ww-
+.CE
+.LP
+Mit cut lassen sich aber auch Strings kürzen.
+.CS
+	$ long=12345678901234567890
+.sp .3
+	$ echo "$long" | cut -c -10
+	1234567890
+.CE
+.LP
+Dieser Befehl gibt die ersten maximal 10 Zeichen von
+\f(CW$long\fP aus. (Alternativ kann man hierfür \f(CWprintf
+"%.10s\\n" "$long"\fP verwenden.)
+.PP
+Geht es aber nicht um die Darstellung von Zeichen, sondern um
+ihre Speicherung, dann ist \f(CW-c\fP nur bedingt geeignet.
+Früher, als US-ASCII noch die omnipräsente Zeichenkodierung
+war, wurde jedes Zeichen mit genau einem
+Byte gespeichert. Somit selektierte \f(CWcut -c\fP gleichermaßen
+sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
+Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
+dieser Annahme lösen. In diesem Zug bekam cut mit
+POSIX.2-1992 einen Bytemodus (Option \f(CW-b\fP). Will man
+also nur die ersten maximal 500 Bytes vor dem
+Newline-Zeichen stehen haben (und den Rest stillschweigend
+ignorieren), dann macht man das mit:
+.CS
+	$ cut -b -500
+.CE
+.LP
+Den Rest kann man sich mit \f(CWcut -b 501-\fP einfangen. Diese
+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 .
+.PP
+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 wurde
+dagegen eine neue Implementierungsweise gefordert. Das Problem
+war folglich nicht, den neuen Bytemodus zu implementieren, sondern
+den Zeichenmodus neu zu implementieren.
+.PP
+Neben dem Zeichen- und Bytemodus bietet cut noch den
+Feldmodus, den man mit \f(CW-f\fP einleitet. Mit ihm
+können Felder ausgewählt werden. Das Trennzeichen (per
+Default der Tab) kann mit \f(CW-d\fP geändert werden. Es gilt in
+gleicher Weise für die Eingabe und die Ausgabe.
+.PP
+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:
+.CS
+	$ cut -d: -f1,3 /etc/passwd
+	root:0
+	bin:1
+	daemon:2
+	mail:8
+	...
+.CE
+.LP
+(Die Argumente für die Optionen können bei cut übrigens
+sowohl mit Whitespace abgetrennt als auch direkt angehängt folgen.)
+.PP
+Dieser Feldmodus ist für einfache tabellarische Dateien,
+wie eben die passwd, gut geeignet. Er kommt aber schnell an
+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 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 gewünschte Verhalten
+für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
+man portabel bleiben will, verwendet man awk in diesen
+Fällen.
+.PP
+Awk bietet noch eine weitere Funktion, die cut missen
+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
+von \f(CWcut -c 5-8,1,4-6\fP 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
+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 führt demnach die Datenbankoperation Projektion auf
+Textdateien aus. Die Wikipedia
+erklärt das folgendermaßen:
+.QP
+Die Projektion entspricht der Projektionsabbildung aus der
+Mengenlehre und kann auch Attributbeschränkung genannt
+werden. Sie extrahiert einzelne Attribute aus der
+ursprünglichen Attributmenge und ist somit als eine Art
+Selektion auf Spaltenebene zu verstehen, das heißt, die
+Projektion blendet Spalten aus. 
+.[[ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
+
+.SH
+Geschichtliches
+.LP
+Cut erblickte 1982 mit dem Release von UNIX System III das
+Licht der öffentlichen Welt. Wenn man die Quellen von System
+III durchforstet, findet man cut.c mit dem Zeitstempel 1980-04-11
+.[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd .
+Das ist die älteste Implementierung des Programms, die ich
+aufstöbern konnte. Allerdings spricht die SCCS-ID im
+Quellcode von Version 1.5. Die Vorgeschichte liegt, der Vermutung
+Doug McIlroys
+.[[ http://minnie.tuhs.org/pipermail/tuhs/2015-May/004083.html
+zufolge, in PWB/UNIX, dessen Entwicklungslinie die Grundlage für
+System III war. In den von PWB 1.0 (1977) verfügbaren Quellen
+.[[ http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/
+ist cut noch nicht zu finden. Von PWB 2.0 scheinen keine
+Quellen oder hilf\%reiche Dokumentation verfügbar zu sein.
+PWB 3.0 wurde später aus Marketinggründen als System III
+bezeichnet und ist folglich mit ihm identisch. Eine Nebenlinie zu
+PWB war CB UNIX, das nur innerhalb
+der Bell Labs genutzt wurde. Das Handbuch von CB UNIX Edition 2.1
+vom November 1979 enthält die früheste Erwähnung von cut, die
+meine Recherche zutage gefördert hat: eine Manpage für cut
+.[[ ftp://sunsite.icm.edu.pl/pub/unix/UnixArchive/PDP-11/Distributions/other/CB_Unix/cbunix_man1_02.pdf .
+.PP
+Nun ein Blick auf die BSD-Linie: Dort ist der früheste
+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 veröffentlicht wurde.
+Die Implementierung unterscheidet sich nur minimal von der
+in System III.
+Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
+Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
+ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
+Marciano Pitargue neu implementiertes cut, das 1989 in BSD
+aufgenommen wurde
+.[[ 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
+erwähnt bereits die erwartete Konformität mit POSIX.2.
+Nun muss man wissen, dass POSIX.2 erst im September
+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 bekräftigt diese Vermutung.
+In der Funktion zum Parsen der Feldauswahlliste findet sich
+dieser Kommentar:
+.QP
+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.
+.LP
+Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits
+ein:
+.QP
+The elements in list can be repeated, can overlap, and can
+be specified in any order.
+.LP
+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.
+Ohne Zugang zu Draft 9 oder 10, war es leider nicht möglich,
+diese Vermutung zu prüfen.
+.PP
+Die Versionsnummern und Änderungsdaten der älteren
+BSD-Implementierungen kann man aus den SCCS-IDs, die vom
+damaligen Versionskontrollsystem in den Code eingefügt wurden,
+ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
+.PP
+Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:
+.CS
+	Copyright (C) 1997-2015 Free Software Foundation, Inc.
+	Copyright (C) 1984 David M. Ihnat
+.CE
+.LP
+Der Code hat also recht alte Ursprünge. Wie aus weiteren
+Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
+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.
+.PP
+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 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 aber schon vertreten. Man muss sich also
+fragen, warum cut überhaupt noch entwickelt wurde, wo es
+schon zwei Programme gab, die die Funktion von cut abdecken
+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 überzeugte. Es wurde in andere Unix Varianten übernommen,
+stan\%dard\%isiert und ist heutzutage überall anzutreffen.
+.PP
+Die ursprüngliche Variante (ohne \f(CW-b\fP) wurde schon 1985 in
+der System V Interface Definition, einer wichtigen formalen
+Beschreibung von UNIX System V, spezifiziert und tauchte
+anschließend in allen relevanten Standards auf. Mit POSIX.2
+im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
+(mit \f(CW-b\fP) standardisiert.
+
+.SH
+Multibyte-Unterstützung
+.LP
+Nun sind der Bytemodus und die damit verbundene
+Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
+1992 standardisiert, wie steht es aber mit deren Umsetzung?
+Welche Versionen implementieren POSIX korrekt?
+Die Situation ist dreiteilig: Es gibt historische
+Implementierungen, die nur \f(CW-c\fP und \f(CW-f\fP kennen. Dann gibt es
+Implementierungen die \f(CW-b\fP zwar kennen, es aber lediglich als Alias
+für \f(CW-c\fP handhaben. Diese Implementierungen funktionieren mit
+Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
+Multibyte-Encodings (z.B. UTF-8) verhält sich ihr \f(CW-c\fP aber
+wie \f(CW-b\fP (und \f(CW-n\fP wird ignoriert). Schließlich gibt es noch
+Implementierungen, die \f(CW-b\fP und \f(CW-c\fP tatsächlich POSIX-konform
+implementieren.
+.PP
+Historische Zwei-Modi-Implementierungen sind die von
+System III, System V und die aller BSDs bis in die 90er.
+.PP
+Pseudo-Multibyte-Implementierungen bieten GNU und die
+modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
+ob dort ein Schein von POSIX-Konformität gewahrt wird.
+Teilweise findet man erst nach genauerer Suche heraus, dass
+\f(CW-c\fP und \f(CW-n\fP nicht wie erwartet funktionieren; teilweise machen es
+sich die Systeme auch einfach, indem sie auf
+Singlebyte-Zeichenkodierungen beharren, das aber dafür
+klar darlegen:
+.QP
+Since we don't support multi-byte characters, the \f(CW-c\fP and \f(CW-b\fP
+options are equivalent, and the \f(CW-n\fP option is meaningless.
+.[[ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
+.LP
+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 großen BSDs diese Änderung nicht
+übernommen haben, bleibt offen. Es scheint aber an der im
+obigen Kommentar formulierten Grundausrichtung zu liegen.
+.PP
+Wie findet man nun als Nutzer heraus, ob beim cut des eigenen
+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 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
+Bytes kodiert ist:
+.CS
+	$ echo ä | od -c
+	0000000 303 244  \\n
+	0000003
+.CE
+.LP
+In diesem Fall sind es zwei Bytes: oktal 303 und 244. (Den
+Zeilenumbruch fügt echo hinzu.)
+.PP
+Mit dem Programm iconv kann man Text explizit in bestimmte
+Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
+bei Latin1 und wie sie bei UTF-8 aussieht:
+.CS
+	$ echo ä | iconv -t latin1 | od -c        
+	0000000 344  \\n
+	0000002
+.sp .3
+	$ echo ä | iconv -t utf8 | od -c  
+	0000000 303 244  \\n
+	0000003
+.CE
+.LP
+Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
+wird recht sicher einer dieser beiden Ausgaben entsprechen.
+.PP
+Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
+dann sollte sich eine POSIX-konforme Implementierung folgendermaßen
+verhalten:
+.CS
+	$ echo ä | cut -c 1 | od -c
+	0000000 303 244  \\n
+	0000003
+.sp .3
+	$ echo ä | cut -b 1 | od -c
+	0000000 303  \\n
+	0000002
+.sp .3
+	$ echo ä | cut -b 1 -n | od -c
+	0000000  \\n
+	0000001
+.CE
+.LP
+Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
+allen drei Fällen wie die mittlere: Es wird das erste Byte
+ausgegeben.
+
+.SH
+Implementierungen
+.LP
+Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
+Implementierungen.
+.PP
+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,
+bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
+erfordert zwangsläufig mehr Code, deshalb sind diese
+Implementierungen tendenziell umfangreicher.
+.TS
+center;
+r r r l l l.
+SLOC	Zeilen	Bytes	Gehört zu  	Dateidatum	Kategorie
+_
+116	123	 2966	System III	1980-04-11	historisch
+118	125	 3038	4.3BSD-UWisc	1986-11-07	historisch
+200	256	 5715	4.3BSD-Reno	1990-06-25	historisch
+200	270	 6545	NetBSD	1993-03-21	historisch
+218	290	 6892	OpenBSD	2008-06-27	pseudo-POSIX
+224	296	 6920	FreeBSD	1994-05-27	historisch
+232	306	 7500	NetBSD 	2014-02-03	pseudo-POSIX
+340	405	 7423	Heirloom	2012-05-20	POSIX
+382	586	14175	GNU coreutils	1992-11-08	pseudo-POSIX
+391	479	10961	FreeBSD	2012-11-24	POSIX
+588	830	23167	GNU coreutils	2015-05-01	pseudo-POSIX
+.TE
+.LP
+Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
+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\(en390 SLOCs. Und schließlich (4) die
+moderne GNU-Variante mit fast 600 SLOCs.
+.PP
+Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
+SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (\f(CWwc
+-l\fP) 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 Größe des Lizenzblocks am Dateianfang. 
+.PP
+Betrachtet man die Abweichungen zwischen den logischen Codezeilen
+und der Dateigröße (\f(CWwc -c\fP), 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 hauptsächlich an deren
+Programmierstil, mit spezieller Einrückung und langen Bezeichnern.
+Ob man die Heirloom-Implementierung
+.[[ http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/cut/cut.c?revision=1.6&view=markup
+als besonders kryptisch
+oder als besonders elegant bezeichnen will, das soll der
+eigenen Einschätzung des Lesers überlassen bleiben. Vor allem
+der Vergleich mit einer GNU-Implementierung
+.[[ http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cut.c;hb=e981643
+ist eindrucksvoll.
+.PP
+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 überführt. Desweiteren
+haben fast alle Implementierungen separate Funktionen für jeden
+ihrer Modi. Bei den POSIX-konformen Implementierungen
+wird die \f(CW-b -n\fP-Kombination als weiterer Modus behandelt, und
+damit in einer eigenen Funktion umgesetzt. Nur bei der frühen
+System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
+wird außer den Fehlerausgaben alles in der main-Funktion
+erledigt.
+.PP
+Cut-Implementierungen haben typischerweise zwei limitierende
+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 (\f(CW_BSD_LINE_MAX\fP bzw. \f(CW_POSIX2_LINE_MAX\fP). Bei modernen
+FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
+Heirloom kann sowohl die Felderanzahl als auch die maximale
+Zeilenlänge beliebig groß werden; der Speicher dafür wird
+dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
+Maximalzahl an Feldern und beliebiger Zeilenlänge. Die
+begrenzte Felderanzahl scheint jedoch kein Praxisproblem
+darzustellen, da \f(CW_POSIX2_LINE_MAX\fP mit mindestens 2048 durchaus
+groß genug sein sollte.
+
+.SH
+Beschreibungen
+.LP
+Interessant ist zudem ein Vergleich der Kurzbeschreibungen von
+cut, wie sie sich in der Titelzeile der Manpages oder manchmal
+am Anfang der Quellcodedatei finden. Die folgende Liste
+ist grob zeitlich geordnet und nach Abstammung gruppiert:
+.TS
+center;
+l l.
+CB UNIX	cut out selected fields of each line of a file
+System III	cut out selected fields of each line of a file
+System III \(dg	cut and paste columns of a table (projection of a relation)
+System V	cut out selected fields of each line of a file
+HP-UX	cut out (extract) selected fields of each line of a file
+.sp .3
+4.3BSD-UWisc \(dg	cut and paste columns of a table (projection of a relation)
+4.3BSD-Reno	select portions of each line of a file
+NetBSD	select portions of each line of a file
+OpenBSD 4.6	select portions of each line of a file
+FreeBSD 1.0	select portions of each line of a file
+FreeBSD 10.0	cut out selected portions of each line of a file
+SunOS 4.1.3	remove selected fields from each line of a file
+SunOS 5.5.1	cut out selected fields of each line of a file
+.sp .3
+Heirloom Tools	cut out selected fields of each line of a file
+Heirloom Tools \(dg	cut out fields of lines of files
+.sp .3
+GNU coreutils	remove sections from each line of files
+.sp .3
+Minix	select out columns of a file
+.sp .3
+Version 8 Unix	rearrange columns of data
+``Unix Reader''	rearrange columns of text
+.sp .3
+POSIX	cut out selected fields of each line of a file
+.TE
+.LP
+Die mit `\(dg' markierten Beschreibungen sind aus dem
+jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält
+die Beschreibung im Standard. Der ``Unix Reader'' ist ein
+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 könnte ein Übertragungsfehler
+oder eine nachträgliche Korrektur sein. Alle übrigen
+Beschreibungen entstammen den Manpages.
+.PP
+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 .
+.PP
+Interessant ist, dass die GNU coreutils seit Anbeginn vom
+Entfernen von Teilen der Eingabe sprechen, wohingegen die
+Kommandozeilenangabe klar ein Auswählen darstellt. Die
+Worte ``cut out'' sind vielleicht auch zu missverständlich.
+HP-UX hat sie deshalb präzisiert.
+.PP
+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).
+.PP
+Die scheinbar unzutreffende Beschreibung
+bei Version 8 Unix (``rearrange columns of data'') ist
+dadurch zu erklären, dass die Manpage sowohl cut als auch
+paste abdeckt. In ihrer Kombination können tatsächlich
+Spalten umgeordnet werden.
+
+.SH
+Referenzen
+.LP
+.nf
+._r
+