# HG changeset patch # User markus schnalke # Date 1431494296 -7200 # Node ID 08f539a5445d04088987a04c37982d304615abca # Parent 4d8196c836d8dc8559eafe962be9efffcd745288 Ueberarbeitung der Formulierungen, hauptsaechlich diff -r 4d8196c836d8 -r 08f539a5445d cut.txt --- a/cut.txt Tue May 12 22:49:21 2015 +0200 +++ b/cut.txt Wed May 13 07:18:16 2015 +0200 @@ -47,8 +47,8 @@ Geht es aber nicht um die Darstellung von Zeichen, sondern um ihre Speicherung, dann ist `-c' nicht unbedingt geeignet. -Frueher, als US-ASCII als Zeichensatz und -kodierung -noch omnipraesent war, wurde jedes Zeichen mit genau einem +Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung +war, wurde jedes Zeichen mit genau einem Byte gespeichert. Somit selektierte `cut -c' gleichermassen sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von @@ -65,45 +65,45 @@ Textdateien mit begrenzter Zeilenlaenge erzeugen kann. [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 -Auch wenn der Bytemodus neu eingefuehrt wurde, so sollte er -sich doch nur so verhalten wie der alte Zeichenmodus normalerweise -implementiert war. Beim Zeichenmodus aber wurde durch POSIX.2 -eine andere Implementierungsweise gefordert. Das Problem war -also nicht, den neuen Bytemodus zu implementieren, sondern +Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte +er sich doch nur so verhalten wie der alte Zeichenmodus +normalerweise schon implementiert war. Beim Zeichenmodus aber +wurde eine neue Implementierungsweise gefordert. Das Problem +war also nicht, den neuen Bytemodus zu implementieren, sondern den Zeichenmodus neu zu implementieren. -Neben dem Zeichen- und Byte-Modus bietet cut noch den -Feld-Modus, den man mit `-f' einleitet. Mit ihm +Neben dem Zeichen- und Bytemodus bietet cut noch den +Feldmodus, den man mit `-f' einleitet. Mit ihm koennen Felder ausgewaehlt werden. Das Trennzeichen (per Default der Tab) kann mit `-d' geaendert werden. -Der typische Anwendungsfall fuer cut im Feld-Modus ist die +Der typische Anwendungsfall fuer cut im Feldmodus ist die Auswahl von Information aus der passwd-Datei. So z.B. der -Benutzername, seine ID und das Homeverzeichnis: +Benutzername und seine ID: - $ cut -d: -f1,3,6 /etc/passwd - root:0:/root - bin:1:/bin - daemon:2:/sbin - mail:8:/var/spool/mail + $ cut -d: -f1,3 /etc/passwd + root:0 + bin:1 + daemon:2 + mail:8 ... (Die Argumente fuer die Optionen koennen bei cut uebrigens mit Whitespace abgetrennt oder direkt angehaengt folgen.) -Dieser Feld-Modus ist fuer einfache tabellarische Dateien, +Dieser Feldmodus ist fuer einfache tabellarische Dateien, wie eben die passwd, gut geeignet. Er kommt aber schnell an seine Grenzen. Gerade der haeufige Fall, dass an Whitespace in Felder geteilt werden soll, wird damit nicht abgedeckt. -Der Delimiter kann nur genau ein Zeichen sein. Es kann also -nicht sowohl an Leerzeichen als auch an Tabs getrennt werden. -Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander +Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann +also nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt +werden. Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander stehende Trennzeichen fuehren 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 aber Erweiterungen, die das gewuenschte Verhalten fuer -Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn +haben deshalb Erweiterungen, die das gewuenschte Verhalten +fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn man portabel bleiben will, verwendet man awk in diesen Faellen. @@ -140,34 +140,32 @@ Zeitstempel 1980-04-11. [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd Das ist die aelteste Manifestation des Programms, die ich -aufstoebern konnte. Allerdings spricht die sccsid im +aufstoebern konnte. Allerdings spricht die SCCS-ID im Quellcode von Version 1.5. Es muss also noch eine Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang gefunden. XXX mail an TUHS -Nun ein Blick auf die BSD-Linie: Dort ist mein -fruehester Fund ein cut.c mit dem Dateimodifikationsdatum -1986-11-07 +Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester +Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut als Teil der Spezialversion 4.3BSD-UWisc, [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix die im Januar 1987 veroeffentlicht wurde. Die Implementierung unterscheidet sich nur minimal von der in System III. -Im bekannteren 4.3BSD-Tahoe (1988) taucht cut nicht auf. -Das darauf folgende 4.3BSD-Reno (1990) liefert aber wieder -ein cut mit aus. Dieses cut ist ein von Adam S. Moskowitz und +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 erwaehnt bereits die erwartete Konformitaet mit POSIX.2. -XXX 2 oder 3 modi? Draft 9: 2 modi? Draft 11.2 hat 3 modi! -Nun sollte man wissen, dass POSIX.2 erst im September +Nun muss man wissen, dass POSIX.2 erst im September 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die -Manpage und das Programm geschrieben wurden. Das Programm +Manpage und das Programm geschrieben worden waren. Das Programm wurde folglich anhand von Arbeitsversionen des Standards implementiert. Ein Blick in den Code bekraeftigt diese Vermutung. In der Funktion zum parsen der Feldauswahlliste findet sich @@ -183,9 +181,15 @@ The elements in list can be repeated, can overlap, and can be specified in any order. -Die Versionsnummern und Aenderungsdatums der aelteren -BSD-Implementierungen kann man aus den SCCS-IDs (die vom -damaligen Versionskontrollsystem in den Code eingefuegt wurden) +Auch listet Draft 11.2 alle drei Modi, waehrend in diesem +BSD cut nur die zwei alten implementiert sind. Es koennte also +sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war. +Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir +leider nicht moeglich, diese Vermutung zu pruefen. XXX + +Die Versionsnummern und Aenderungsdaten der aelteren +BSD-Implementierungen kann man aus den SCCS-IDs, die vom +damaligen Versionskontrollsystem in den Code eingefuegt wurden, ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk: @@ -193,12 +197,12 @@ Copyright (C) 1997-2015 Free Software Foundation, Inc. Copyright (C) 1984 David M. Ihnat -Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren -Kommentaren zu entnehmen ist, wurde der Code zuerst von David +Der Code hat also recht alte Urspruenge. Wie aus weiteren +Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer hat den Code 1992 auch ins Versionkontrollsystem eingestellt. -Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk -auftauchen, ist unklar. +Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im +Copyright-Vermerk auftauchen, ist unklar. Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut, aus Sicht des urspruenglichen Unix, zu den juengeren Tools. @@ -212,8 +216,8 @@ schon zwei Programme gab, die die Funktion von cut abdecken konnten. Ein Argument fuer cut war sicher seine Kompaktheit und die damit verbundene Geschwindigkeit gegenueber dem damals -traegen awk. Diese schlanke Gestalt ist es auch, die der Unix -Philosopie entspricht: Mache eine Aufgabe und die richtig! +traegen awk. Diese schlanke Gestalt ist es auch, die der +Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig! Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen, standardisiert und ist heutzutage ueberall anzutreffen. @@ -232,27 +236,27 @@ 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 traditionelle +Die Situation ist dreiteilig: Es gibt historische Implementierungen, die nur -c und -f kennen. Dann gibt es Implementierungen die -b zwar kennen, es aber lediglich als Alias fuer -c handhaben. Diese Implementierungen funktionieren mit Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei -Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber +Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber wie -b (und -n wird ignoriert). Schliesslich gibt es noch Implementierungen, die -b und -c tatsaechlich POSIX-konform implementieren. -Traditionelle Zwei-Modi-Implementierungen sind z.B. die von +Historische Zwei-Modi-Implementierungen sind z.B. die von System III, System V und die aller BSDs bis in die 90er. Pseudo-Multibyte-Implementierungen bieten GNU und die -modernen NetBSDs und OpenBSDs. Man darf sich durchaus fragen, +modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen, ob dort ein Schein von POSIX-Konformitaet gewahrt wird. Teilweise findet man erst nach genauerer Suche heraus, dass -c und -n nicht wie erwartet funktionieren; teilweise machen es -sich die System auch einfach, indem sie auf -Singlebyte-Zeichenkodierungen beharren, das aber dafuer klar -darlegen: +sich die Systeme auch einfach, indem sie auf +Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist +klar darlegen: Since we don't support multi-byte characters, the -c and -b options are equivalent, and the -n option is meaningless. @@ -268,10 +272,10 @@ uebernommen haben, bleibt offen. Es scheint aber an der im obigen Kommentar formulierten Grundausrichtung zu liegen. -Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen +Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen Systems Multibytes korrekt unterstuetzt werden? Zuerst ist entscheidend, ob das System selbst mit einem Multibyte-Encoding -arbeitet, denn tut es das nicht, dann entsprechen sich naemlich +arbeitet, denn tut es das nicht, dann entsprechen sich Zeichen und Bytes und die Frage eruebrigt sich. Man kann das herausfinden indem man sich das Locale anschaut, aber einfacher ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut, @@ -301,7 +305,8 @@ wird recht sicher einer dieser beiden Ausgaben entsprechen. Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System, -dann sollte sich eine POSIX-konforme Implementierung so verhalten: +dann sollte sich eine POSIX-konforme Implementierung folgendermassen +verhalten: $ echo ä | ./cut -c 1 | od -c 0000000 303 244 \n @@ -328,19 +333,19 @@ Fuer einen ersten Eindruck ist der Umfang des Quellcodes hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall, -bestaetigt werden. Die Unterstuetzung des Byte-Modus (-b) -erfordert zwangslaeufig mehr Code, deshalb sind die -POSIX-konformen Implementierungen tendenziell umfangreicher. +bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus +erfordert zwangslaeufig mehr Code, deshalb sind diese +Implementierungen tendenziell umfangreicher. SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie ----------------------------------------------------------------- - 116 123 2966 System III 1980-04-11 (trad) - 118 125 3038 4.3BSD-UWisc 1986-11-07 (trad) - 200 256 5715 4.3BSD-Reno 1990-06-25 (trad) - 200 270 6545 NetBSD 1993-03-21 (trad) + 116 123 2966 System III 1980-04-11 (hist) + 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist) + 200 256 5715 4.3BSD-Reno 1990-06-25 (hist) + 200 270 6545 NetBSD 1993-03-21 (hist) 218 290 6892 OpenBSD 2008-06-27 (pseudo) - 224 296 6920 FreeBSD 1994-05-27 (trad) + 224 296 6920 FreeBSD 1994-05-27 (hist) 232 306 7500 NetBSD 2014-02-03 (pseudo) 340 405 7423 Heirloom 2012-05-20 (POSIX) 382 586 14175 GNU coreutils 1992-11-08 (pseudo) @@ -352,8 +357,8 @@ urspruenglichen Implementierungen, die sich nur minimal unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und -die alte GNU-Version mit 340-390 SLOCs. Und (4) die moderne -GNU-Variante mit fast 600 SLOCs. +die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die +moderne GNU-Variante mit fast 600 SLOCs. Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc @@ -366,15 +371,15 @@ und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit -fast 40 nach oben. Dies liegt bei GNU hauptsaechlich an deren +fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren Programmierstil, mit spezieller Einrueckung und langen Bezeichnern. Ob man die Heirloom-Implementierung als besonders kryptisch oder als besonders elegant bezeichnen will, das soll der eigenen Einschaetzung des Lesers ueberlassen bleiben. -Die interne Struktur des C-Codes ist meist aehnlich. Neben der -obligatorischen main-Funktion, die die Kommandozeilenargumente +Die interne Struktur der Programmcodes (in C) ist meist aehnlich. +Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente verarbeitet, gibt es im Normalfall eine Funktion, die die Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren haben fast alle Implementierungen separate Funktionen fuer die @@ -382,28 +387,28 @@ wird die `-b -n'-Kombination als weiterer Modus behandelt, und damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) -wird ausser den Fehlerausgaben nichts aus der main-Funktion -ausgelagert. +wird ausser den Fehlerausgaben alles in der main-Funktion +erledigt. Cut-Implementierungen haben typischerweise zwei limitierende Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale -Zeilenlaenge. Bei System III ist die Anzahl der moeglichen Felder -und ebenso die Zeilenlaenge auf 512 begrenzt. 4.3BSD-Reno und die -BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX -bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei -allen GNU-Implementierungen und bei Heirloom kann sowohl -die Felderanzahl als auch die maximale Zeilenlaenge beliebig -gross werden; der Speicher dafür wird dynamisch alloziiert. -OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber -beliebiger Zeilenlaenge. Die begrenzte Felderanzahl scheint -jedoch kein praktisches Problem darzustellen, da _POSIX2_LINE_MAX -mit mindestens 2048 durchaus genug Platz bieten sollte. +Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt. +4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe +Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen +FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei +Heirloom kann sowohl die Felderanzahl als auch die maximale +Zeilenlaenge beliebig gross werden; der Speicher dafür wird +dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer +Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die +begrenzte Felderanzahl scheint jedoch kein Praxisproblem +darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus +gross genug sein sollte. Beschreibungen Interessant ist auch ein Vergleich der Kurzbeschreibungen von -cut, wie sie sich in der Titelzeile von Manpages oder manchmal +cut, wie sie sich in der Titelzeile der Manpages oder manchmal auch am Anfang der Quellcodedatei finden. Die folgende Liste ist grob zeitlich geordnet und nach Abstammung gruppiert: @@ -436,32 +441,30 @@ Die mit ``(src)'' markierten Beschreibungen sind aus dem -jeweiligen Quellcode entnommen. -Der POSIX-Eintrag enthaelt die Beschreibung des Standards. -Der ``Unix Reader'' ist ein rueckblickendes Textdokument von -Doug McIlroy, das das Auftreten von Tools in der Geschichte -des Research Unix zum Thema hat. +jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt +die Beschreibung des Standards. Der ``Unix Reader'' ist ein +rueckblickendes Textdokument von Doug McIlroy, das das +Auftreten von Tools in der Geschichte des Research Unix zum +Thema hat. [ http://doc.cat-v.org/unix/unix-reader/contents.pdf -Eigentlich sollte seine -Beschreibung der in Version 8 Unix entsprechen. Die -Abweichung koennte sowohl ein Uebertragungsfehler als auch -eine nachtraegliche Korrektur sein. -Alle uebrigen Beschreibungen entstammen den Manpages. +Eigentlich sollte seine Beschreibung der in Version 8 Unix +entsprechen. Die Abweichung koennte sowohl ein +Uebertragungsfehler als auch eine nachtraegliche Korrektur +sein. Alle uebrigen Beschreibungen entstammen den Manpages. Oft ist mit der Zeit die POSIX-Beschreibung uebernommen -oder zumindest an sie angeglichen worden, wie beispielsweise -bei FreeBSD. +oder an sie angeglichen worden, wie beispielsweise bei FreeBSD. [ https://svnweb.freebsd.org/base?view=revision&revision=167101 Interessant ist, dass die GNU coreutils seit Anbeginn vom Entfernen von Teilen der Eingabe sprechen, wohingegen die Kommandozeilenangabe klar ein Auswaehlen darstellt. Die -Worte ``cut out'' sind vielleicht auch nur etwas zu +Worte ``cut out'' sind vielleicht auch etwas zu missverstaendlich. HP-UX hat sie deshalb praezisiert. Auch beim Begriff, was selektiert wird, ist man sich -uneins. Die einen reden von Feldern (POSIX), andere von -Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten +uneins. Die Einen reden von Feldern (POSIX), Andere von +Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten (Research Unix). Ironischerweise leistet sich gerade Version 8 Unix, das eigentlich um eine sehr treffende Weltsicht bemueht ist, mit ``rearrange columns of data'' die