meillo@6: cut - cut out selected fields of each line of a file meillo@6: ---------------------------------------------------- meillo@6: markus schnalke meillo@6: 2015-05 meillo@0: meillo@0: meillo@1: Cut ist ein klassisches Programm im Unix-Werkzeugkasten. meillo@8: In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt meillo@21: es, denn es ist ein schönes, praktisches und anschauliches meillo@9: Helferlein. Hier soll ein wenig hinter seine Fassade geschaut meillo@9: werden. meillo@0: meillo@0: meillo@4: Funktionsweise meillo@4: meillo@21: Ursprünglich hatte cut zwei Modi, die später um einen dritten meillo@21: erweitert wurden. Cut schneidet entweder gewünschte Zeichen aus meillo@21: den Zeilen der Eingabe oder gewünschte, durch Trennzeichen meillo@8: definierte, Felder. meillo@0: meillo@9: Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu meillo@19: zerteilen. Man kann damit beispielsweise bestimmte meillo@9: Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in meillo@9: diesem Beispiel die Rechte des Besitzers: meillo@0: meillo@15: $ ls -l foo meillo@15: -rw-rw-r-- 1 meillo users 0 May 12 07:32 foo meillo@15: meillo@4: $ ls -l foo | cut -c 2-4 meillo@4: rw- meillo@0: meillo@4: Oder die Schreibrechte des Besitzers, der Gruppe und der meillo@4: Welt: meillo@0: meillo@4: $ ls -l | cut -c 3,6,9 meillo@4: ww- meillo@0: meillo@21: Mit cut lassen sich aber auch Strings kürzen. meillo@0: meillo@10: $ long=12345678901234567890 meillo@10: $ echo "$long" | cut -c -10 meillo@10: 1234567890 meillo@0: meillo@10: Dieser Befehl gibt die ersten maximal 10 Zeichen von meillo@21: `$long' aus. (Alternativ kann man hierfür `printf meillo@10: "%.10s\n" "$long"' verwenden.) meillo@0: meillo@4: Geht es aber nicht um die Darstellung von Zeichen, sondern um meillo@8: ihre Speicherung, dann ist `-c' nicht unbedingt geeignet. meillo@21: Früher, als US-ASCII noch die omnipräsente Zeichenkodierung meillo@17: war, wurde jedes Zeichen mit genau einem meillo@21: Byte gespeichert. Somit selektierte `cut -c' gleichermaßen meillo@4: sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von meillo@4: Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von meillo@21: dieser Annahme lösen. In diesem Zug bekam cut mit meillo@9: POSIX.2-1992 einen Bytemodus (Option `-b'). Will man meillo@4: also nur die ersten maximal 500 Bytes vor dem meillo@0: Newline-Zeichen stehen haben (und den Rest stillschweigend meillo@0: ignorieren), dann macht man das mit: meillo@0: meillo@6: $ cut -b -500 meillo@0: meillo@4: Den Rest kann man sich mit `cut -b 501-' einfangen. Diese meillo@21: Funktion ist insbesondere für POSIX wichtig, da man damit meillo@21: Textdateien mit begrenzter Zeilenlänge erzeugen kann. meillo@4: [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 meillo@0: meillo@21: Wenn auch der Bytemodus neu eingeführt worden war, so sollte meillo@17: er sich doch nur so verhalten wie der alte Zeichenmodus meillo@17: normalerweise schon implementiert war. Beim Zeichenmodus aber meillo@17: wurde eine neue Implementierungsweise gefordert. Das Problem meillo@19: war folglich nicht, den neuen Bytemodus zu implementieren, sondern meillo@10: den Zeichenmodus neu zu implementieren. meillo@10: meillo@17: Neben dem Zeichen- und Bytemodus bietet cut noch den meillo@17: Feldmodus, den man mit `-f' einleitet. Mit ihm meillo@21: können Felder ausgewählt werden. Das Trennzeichen (per meillo@21: Default der Tab) kann mit `-d' geändert werden. Es gilt in meillo@21: gleicher Weise für die Eingabe und die Ausgabe. meillo@0: meillo@21: Der typische Anwendungsfall für cut im Feldmodus ist die meillo@19: Auswahl von Information aus der passwd-Datei. Hier z.B. der meillo@17: Benutzername und seine ID: meillo@0: meillo@17: $ cut -d: -f1,3 /etc/passwd meillo@17: root:0 meillo@17: bin:1 meillo@17: daemon:2 meillo@17: mail:8 meillo@9: ... meillo@0: meillo@21: (Die Argumente für die Optionen können bei cut übrigens meillo@21: mit Whitespace abgetrennt oder direkt angehängt folgen.) meillo@0: meillo@21: Dieser Feldmodus ist für einfache tabellarische Dateien, meillo@4: wie eben die passwd, gut geeignet. Er kommt aber schnell an meillo@21: seine Grenzen. Gerade der häufige Fall, dass an Whitespace meillo@0: in Felder geteilt werden soll, wird damit nicht abgedeckt. meillo@17: Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann meillo@19: demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt meillo@19: werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander meillo@21: stehende Trennzeichen führen zu einem leeren Feld. Dieses meillo@8: Verhalten widerspricht den Erwartungen, die man an die meillo@8: Verarbeitung einer Datei mit Whitespace-getrennten Feldern meillo@8: hat. Manche Implementierungen von cut, z.B. die von FreeBSD, meillo@21: haben deshalb Erweiterungen, die das gewünschte Verhalten meillo@21: für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn meillo@9: man portabel bleiben will, verwendet man awk in diesen meillo@21: Fällen. meillo@0: meillo@4: Awk bietet noch eine weitere Funktion, die cut missen meillo@21: lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei meillo@8: cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein meillo@19: Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt meillo@19: der Aufruf meillo@8: von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8 meillo@8: in genau dieser Reihenfolge aus. Die Auswahl entspricht damit meillo@8: der Mengenlehre in der Mathematik: Jedes angegebene Feld wird meillo@9: Teil der Ergebnismenge. Die Felder der Ergebnismenge sind meillo@19: hierbei immer gleich geordnet wie in der Eingabe. Um die Worte meillo@16: der Manpage von Version 8 Unix wiederzugeben: ``In data base meillo@9: parlance, it projects a relation.'' meillo@16: [ http://man.cat-v.org/unix_8th/1/cut meillo@21: Cut führt demnach die Datenbankoperation Projektion auf meillo@21: Textdateien aus. Die Wikipedia erklärt das folgendermaßen: meillo@7: meillo@7: Die Projektion entspricht der Projektionsabbildung aus der meillo@7: Mengenlehre und kann auch Attributbeschränkung genannt meillo@7: werden. Sie extrahiert einzelne Attribute aus der meillo@7: ursprünglichen Attributmenge und ist somit als eine Art meillo@7: Selektion auf Spaltenebene zu verstehen, das heißt, die meillo@7: Projektion blendet Spalten aus. meillo@7: meillo@8: [ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion meillo@8: meillo@7: meillo@0: Geschichtliches meillo@0: meillo@4: Cut erblickte 1982 mit dem Release von UNIX System III das meillo@21: Licht der öffentlichen Welt. Wenn man die Quellen von System meillo@4: III durchforstet, findet man die Quellcodedatei cut.c mit dem meillo@4: Zeitstempel 1980-04-11. meillo@1: [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd meillo@21: Das ist die älteste Manifestation des Programms, die ich meillo@21: aufstöbern konnte. Allerdings spricht die SCCS-ID im meillo@20: Quellcode von Version 1.5. Die Vorgeschichte liegt, der Aussage meillo@20: Doug McIlroys meillo@20: [ XXX meillo@21: zufolge, in PWB/UNIX, das die Grundlage für System III war. meillo@20: (PWB 3.0 entspricht System III.) In den von PWB 1.0 (1977) meillo@21: verfügbaren Quellen meillo@20: [ XXX meillo@20: ist cut noch nicht zu finden; von PWB 2.0 sind mir keine meillo@21: verfügbaren Quellen oder hilfreiche Dokumentation bekannt. meillo@0: meillo@21: Nun ein Blick auf die BSD-Linie: Dort ist mein frühester meillo@17: Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07 meillo@8: [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut meillo@8: als Teil der Spezialversion 4.3BSD-UWisc, meillo@6: [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix meillo@21: die im Januar 1987 veröffentlicht wurde. meillo@8: Die Implementierung unterscheidet sich nur minimal von der meillo@8: in System III. meillo@17: Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf. meillo@17: Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder meillo@17: ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und meillo@8: Marciano Pitargue neu implementiertes cut, das 1989 in BSD meillo@8: aufgenommen wurde. meillo@1: [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut meillo@4: Seine Manpage meillo@1: [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1 meillo@21: erwähnt bereits die erwartete Konformität mit POSIX.2. meillo@17: Nun muss man wissen, dass POSIX.2 erst im September meillo@21: 1992 veröffentlicht wurde, erst gut zwei Jahren nachdem die meillo@17: Manpage und das Programm geschrieben worden waren. Das Programm meillo@10: wurde folglich anhand von Arbeitsversionen des Standards meillo@21: implementiert. Ein Blick in den Code bekräftigt diese Vermutung. meillo@15: In der Funktion zum parsen der Feldauswahlliste findet sich meillo@15: dieser Kommentar: meillo@0: meillo@15: This parser is less restrictive than the Draft 9 POSIX spec. meillo@15: POSIX doesn't allow lists that aren't in increasing order or meillo@15: overlapping lists. meillo@9: meillo@21: Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits meillo@15: ein: meillo@12: meillo@15: The elements in list can be repeated, can overlap, and can meillo@15: be specified in any order. meillo@15: meillo@21: Zudem listet Draft 11.2 alle drei Modi, während in diesem meillo@21: BSD cut nur die zwei alten implementiert sind. Es könnte also meillo@17: sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war. meillo@17: Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir meillo@21: leider nicht möglich, diese Vermutung zu prüfen. meillo@17: meillo@21: Die Versionsnummern und Änderungsdaten der älteren meillo@17: BSD-Implementierungen kann man aus den SCCS-IDs, die vom meillo@21: damaligen Versionskontrollsystem in den Code eingefügt wurden, meillo@15: ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. meillo@12: meillo@21: Das cut der GNU Coreutils enthält folgenden Copyrightvermerk: meillo@12: meillo@12: Copyright (C) 1997-2015 Free Software Foundation, Inc. meillo@12: Copyright (C) 1984 David M. Ihnat meillo@12: meillo@21: Der Code hat also recht alte Ursprünge. Wie aus weiteren meillo@17: Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David meillo@21: MacKenzie und später von Jim Meyering überarbeitet. Letzterer meillo@12: hat den Code 1992 auch ins Versionkontrollsystem eingestellt. meillo@17: Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im meillo@17: Copyright-Vermerk auftauchen, ist unklar. meillo@12: meillo@21: Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut, meillo@21: aus Sicht des ursprünglichen Unix, zu den jüngeren Tools. meillo@21: Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist, meillo@21: so war Unix doch schon über zehn Jahre alt, als cut das meillo@21: erste Mal auftauchte. Insbesondere gehörte cut noch nicht meillo@4: zu Version 7 Unix, das die Ausgangsbasis aller modernen meillo@4: Unix-Systeme darstellt. Die weit komplexeren Programme sed meillo@4: und awk waren dort schon vertreten. Man muss sich also meillo@21: fragen, warum cut überhaupt noch entwickelt wurde, wo es meillo@9: schon zwei Programme gab, die die Funktion von cut abdecken meillo@21: konnten. Ein Argument für cut war sicher seine Kompaktheit und meillo@21: die damit verbundene Geschwindigkeit gegenüber dem damals meillo@21: trägen awk. Diese schlanke Gestalt ist es auch, die der meillo@17: Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig! meillo@21: Cut überzeugte. Es wurde in andere Unix Varianten übernommen, meillo@21: standardisiert und ist heutzutage überall anzutreffen. meillo@1: meillo@21: Die ursprüngliche Variante (ohne -b) wurde schon 1985 in meillo@5: der System V Interface Definition, einer wichtigen formalen meillo@9: Beschreibung von UNIX System V, spezifiziert und tauchte meillo@21: anschließend in allen relevanten Standards auf. Mit POSIX.2 meillo@9: im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form meillo@9: (mit -b) standardisiert. meillo@1: meillo@1: meillo@21: Multibyte-Unterstützung meillo@8: meillo@8: Nun sind der Bytemodus und die damit verbundene meillo@8: Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit meillo@8: 1992 standardisiert, wie steht es aber mit deren Umsetzung? meillo@10: Welche Versionen implementieren POSIX korrekt? meillo@17: Die Situation ist dreiteilig: Es gibt historische meillo@8: Implementierungen, die nur -c und -f kennen. Dann gibt es meillo@10: Implementierungen die -b zwar kennen, es aber lediglich als Alias meillo@21: für -c handhaben. Diese Implementierungen funktionieren mit meillo@8: Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei meillo@21: Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber meillo@21: wie -b (und -n wird ignoriert). Schließlich gibt es noch meillo@21: Implementierungen, die -b und -c tatsächlich POSIX-konform meillo@8: implementieren. meillo@8: meillo@17: Historische Zwei-Modi-Implementierungen sind z.B. die von meillo@8: System III, System V und die aller BSDs bis in die 90er. meillo@8: meillo@10: Pseudo-Multibyte-Implementierungen bieten GNU und die meillo@17: modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen, meillo@21: ob dort ein Schein von POSIX-Konformität gewahrt wird. meillo@15: Teilweise findet man erst nach genauerer Suche heraus, dass meillo@15: -c und -n nicht wie erwartet funktionieren; teilweise machen es meillo@17: sich die Systeme auch einfach, indem sie auf meillo@21: Singlebyte-Zeichenkodierungen beharren, das aber dafür meist meillo@17: klar darlegen: meillo@8: meillo@15: Since we don't support multi-byte characters, the -c and -b meillo@15: options are equivalent, and the -n option is meaningless. meillo@8: meillo@16: [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup meillo@8: meillo@21: Tatsächlich standardkonforme Implementierungen, die meillo@8: Multibytes korrekt handhaben, bekommt man bei einem modernen meillo@8: FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins meillo@9: im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert. meillo@8: [ https://svnweb.freebsd.org/base?view=revision&revision=131194 meillo@21: Warum die beiden anderen großen BSDs diese Änderung nicht meillo@21: übernommen haben, bleibt offen. Es scheint aber an der im meillo@8: obigen Kommentar formulierten Grundausrichtung zu liegen. meillo@8: meillo@17: Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen meillo@21: Systems Multibytes korrekt unterstützt werden? Zuerst ist meillo@8: entscheidend, ob das System selbst mit einem Multibyte-Encoding meillo@17: arbeitet, denn tut es das nicht, dann entsprechen sich meillo@21: Zeichen und Bytes und die Frage erübrigt sich. Man kann das meillo@9: herausfinden indem man sich das Locale anschaut, aber einfacher meillo@9: ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut, meillo@9: auszugeben und zu schauen ob dieses in einem oder in mehreren meillo@9: Bytes kodiert ist: meillo@8: meillo@8: $ echo ä | od -c meillo@8: 0000000 303 244 \n meillo@8: 0000003 meillo@8: meillo@8: In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den meillo@21: Zeilenumbruch fügt echo(1) hinzu.) meillo@8: meillo@9: Mit dem Programm iconv(1) kann man Text explizit in bestimmte meillo@10: Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe meillo@10: bei Latin1 und wie sie bei UTF-8 aussieht. meillo@8: meillo@8: $ echo ä | iconv -t latin1 | od -c meillo@8: 0000000 344 \n meillo@8: 0000002 meillo@8: meillo@8: $ echo ä | iconv -t utf8 | od -c meillo@8: 0000000 303 244 \n meillo@8: 0000003 meillo@8: meillo@8: Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung) meillo@8: wird recht sicher einer dieser beiden Ausgaben entsprechen. meillo@8: meillo@8: Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System, meillo@21: dann sollte sich eine POSIX-konforme Implementierung folgendermaßen meillo@17: verhalten: meillo@8: meillo@18: $ echo ä | cut -c 1 | od -c meillo@10: 0000000 303 244 \n meillo@8: 0000003 meillo@8: meillo@18: $ echo ä | cut -b 1 | od -c meillo@10: 0000000 303 \n meillo@8: 0000002 meillo@8: meillo@18: $ echo ä | cut -b 1 -n | od -c meillo@10: 0000000 \n meillo@10: 0000001 meillo@10: meillo@10: Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in meillo@21: allen drei Fällen wie die mittlere: Es wird das erste Byte meillo@10: ausgegeben. meillo@8: meillo@8: meillo@8: Implementierungen meillo@8: meillo@9: Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an meillo@9: Implementierungen. meillo@9: meillo@21: Für einen ersten Eindruck ist der Umfang des Quellcodes meillo@21: hilfreich. Typischerweise steigt dieser über die Jahre an. Diese meillo@8: Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall, meillo@21: bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus meillo@21: erfordert zwangsläufig mehr Code, deshalb sind diese meillo@17: Implementierungen tendenziell umfangreicher. meillo@8: meillo@8: meillo@21: SLOC Zeilen Bytes Gehört zu Dateidatum Kategorie meillo@9: ----------------------------------------------------------------- meillo@17: 116 123 2966 System III 1980-04-11 (hist) meillo@17: 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist) meillo@17: 200 256 5715 4.3BSD-Reno 1990-06-25 (hist) meillo@17: 200 270 6545 NetBSD 1993-03-21 (hist) meillo@9: 218 290 6892 OpenBSD 2008-06-27 (pseudo) meillo@17: 224 296 6920 FreeBSD 1994-05-27 (hist) meillo@9: 232 306 7500 NetBSD 2014-02-03 (pseudo) meillo@9: 340 405 7423 Heirloom 2012-05-20 (POSIX) meillo@9: 382 586 14175 GNU coreutils 1992-11-08 (pseudo) meillo@9: 391 479 10961 FreeBSD 2012-11-24 (POSIX) meillo@9: 588 830 23167 GNU coreutils 2015-05-01 (pseudo) meillo@8: meillo@8: meillo@9: Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei meillo@21: ursprünglichen Implementierungen, die sich nur minimal meillo@21: unterscheiden, mit gut 100 SLOCs. (2) Die fünf BSD-Versionen mit meillo@9: gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und meillo@21: die alte GNU-Version mit 340-390 SLOCs. Und schließlich (4) die meillo@17: moderne GNU-Variante mit fast 600 SLOCs. meillo@8: meillo@9: Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit meillo@21: SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (`wc meillo@21: -l') erstreckt sich über eine Spanne von Faktor 1.06 bei den meillo@21: ältesten Vertretern bis zu Faktor 1.5 bei GNU. Den größten meillo@19: Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und meillo@21: die Größe des Lizenzblocks am Dateianfang. meillo@8: meillo@9: Betrachtet man die Abweichungen zwischen den logischen Codezeilen meillo@21: und der Dateigröße (`wc -c'), so pendelt das Teilnehmerfeld meillo@9: zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung meillo@9: weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit meillo@21: fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren meillo@21: Programmierstil, mit spezieller Einrückung und langen Bezeichnern. meillo@21: Ob man die Heirloom-Implementierung meillo@21: [ XXX meillo@21: als besonders kryptisch meillo@9: oder als besonders elegant bezeichnen will, das soll der meillo@21: eigenen Einschätzung des Lesers überlassen bleiben. Vor allem meillo@21: der Vergleich mit einer GNU-Implementierung meillo@21: [ XXX meillo@21: ist eindrucksvoll. meillo@8: meillo@8: meillo@21: Die interne Struktur der Programmcodes (in C) ist meist ähnlich. meillo@17: Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente meillo@11: verarbeitet, gibt es im Normalfall eine Funktion, die die meillo@21: Feldauswahl in eine interne Datenstruktur überführt. Desweiteren meillo@21: haben fast alle Implementierungen separate Funktionen für die meillo@19: zwei oder drei Modi. Bei den POSIX-konformen Implementierungen meillo@11: wird die `-b -n'-Kombination als weiterer Modus behandelt, und meillo@21: damit in einer eigenen Funktion umgesetzt. Nur bei der frühen meillo@11: System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) meillo@21: wird außer den Fehlerausgaben alles in der main-Funktion meillo@17: erledigt. meillo@11: meillo@15: Cut-Implementierungen haben typischerweise zwei limitierende meillo@21: Größen: Die Maximalanzahl unterstützter Felder und die maximale meillo@21: Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt. meillo@17: 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe meillo@17: Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen meillo@17: FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei meillo@17: Heirloom kann sowohl die Felderanzahl als auch die maximale meillo@21: Zeilenlänge beliebig groß werden; der Speicher dafür wird meillo@17: dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer meillo@21: Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die meillo@17: begrenzte Felderanzahl scheint jedoch kein Praxisproblem meillo@17: darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus meillo@21: groß genug sein sollte. meillo@11: meillo@8: meillo@2: Beschreibungen meillo@1: meillo@19: Interessant ist zudem ein Vergleich der Kurzbeschreibungen von meillo@17: cut, wie sie sich in der Titelzeile der Manpages oder manchmal meillo@19: am Anfang der Quellcodedatei finden. Die folgende Liste meillo@9: ist grob zeitlich geordnet und nach Abstammung gruppiert: meillo@3: meillo@3: meillo@2: System III cut out selected fields of each line of a file meillo@3: System III (src) cut and paste columns of a table (projection of a relation) meillo@2: System V cut out selected fields of each line of a file meillo@2: HP-UX cut out (extract) selected fields of each line of a file meillo@2: meillo@3: 4.3BSD-UWisc (src) cut and paste columns of a table (projection of a relation) meillo@2: 4.3BSD-Reno select portions of each line of a file meillo@2: NetBSD select portions of each line of a file meillo@7: OpenBSD 4.6 select portions of each line of a file meillo@2: FreeBSD 1.0 select portions of each line of a file meillo@10: FreeBSD 10.0 cut out selected portions of each line of a file meillo@2: SunOS 4.1.3 remove selected fields from each line of a file meillo@2: SunOS 5.5.1 cut out selected fields of each line of a file meillo@2: meillo@8: Heirloom Tools cut out selected fields of each line of a file meillo@9: Heirloom Tools (src) cut out fields of lines of files meillo@2: meillo@2: GNU coreutils remove sections from each line of files meillo@2: meillo@2: Minix select out columns of a file meillo@2: meillo@2: Version 8 Unix rearrange columns of data meillo@2: ``Unix Reader'' rearrange columns of text meillo@2: meillo@9: POSIX cut out selected fields of each line of a file meillo@2: meillo@9: meillo@9: Die mit ``(src)'' markierten Beschreibungen sind aus dem meillo@21: jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält meillo@18: die Beschreibung im Standard. Der ``Unix Reader'' ist ein meillo@21: rückblickendes Textdokument von Doug McIlroy, das das meillo@18: Auftreten der Tools in der Geschichte des Research Unix zum meillo@17: Thema hat. meillo@16: [ http://doc.cat-v.org/unix/unix-reader/contents.pdf meillo@17: Eigentlich sollte seine Beschreibung der in Version 8 Unix meillo@21: entsprechen. Die Abweichung könnte ein Übertragungsfehler meillo@21: oder eine nachträgliche Korrektur sein. Alle übrigen meillo@19: Beschreibungen entstammen den Manpages. meillo@5: meillo@21: Oft ist mit der Zeit die POSIX-Beschreibung übernommen meillo@17: oder an sie angeglichen worden, wie beispielsweise bei FreeBSD. meillo@5: [ https://svnweb.freebsd.org/base?view=revision&revision=167101 meillo@5: meillo@7: Interessant ist, dass die GNU coreutils seit Anbeginn vom meillo@5: Entfernen von Teilen der Eingabe sprechen, wohingegen die meillo@21: Kommandozeilenangabe klar ein Auswählen darstellt. Die meillo@21: Worte ``cut out'' sind vielleicht auch zu missverständlich. meillo@21: HP-UX hat sie deshalb präzisiert. meillo@5: meillo@19: Beim Begriff, was selektiert wird, ist man sich ebenfalls meillo@17: uneins. Die Einen reden von Feldern (POSIX), Andere von meillo@17: Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten meillo@5: (Research Unix). Ironischerweise leistet sich gerade Version meillo@5: 8 Unix, das eigentlich um eine sehr treffende Weltsicht meillo@21: bemüht ist, mit ``rearrange columns of data'' die meillo@5: unzutreffendste der Beschreibungen. meillo@5: meillo@5: meillo@6: Autoreninfo meillo@6: meillo@21: Markus Schnalke interessiert sich für die Hintergründe meillo@21: von Unix und seinen Werkzeugen. Für die Erarbeitung dieses meillo@6: Textes wurde er regelrecht zum Historiker. meillo@6: meillo@6: meillo@6: Lizenz meillo@10: meillo@6: CC0 (und kann damit auch unter CC BY-SA 4.0 Unported meillo@21: veröffentlicht werden)