# HG changeset patch # User markus schnalke # Date 1431320940 -7200 # Node ID 7e1214b556b98c5192489f3d831814f748e3c897 # Parent e67bd0d48bd60dde259d1f5a88998a6d85518bcb Zwischenstand diff -r e67bd0d48bd6 -r 7e1214b556b9 cut.txt --- a/cut.txt Tue May 05 19:21:00 2015 +0200 +++ b/cut.txt Mon May 11 07:09:00 2015 +0200 @@ -36,11 +36,13 @@ Mit cut lassen sich aber auch Strings kuerzen. - $ echo "$long" | cut -c -20 + $ long=12345678901234567890 + $ echo "$long" | cut -c -10 + 1234567890 -Dieser Befehl gibt die ersten maximal 20 Zeichen von +Dieser Befehl gibt die ersten maximal 10 Zeichen von `$long' aus. (Alternativ kann man hierfuer auch `printf -"%.20s\n" "$long"' verwenden.) +"%.10s\n" "$long"' verwenden.) Geht es aber nicht um die Darstellung von Zeichen, sondern um ihre Speicherung, dann ist `-c' nicht unbedingt geeignet. @@ -62,14 +64,21 @@ Textdateien mit begrenzter Zeilenlaenge erzeugen kann. [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 -Neben dem Zeichen- bzw. Byte-Modus bietet cut noch den +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 +den Zeichenmodus neu zu implementieren. + +Neben dem Zeichen- und Byte-Modus bietet cut noch den Feld-Modus, 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 Auswahl von Information aus der passwd-Datei. So z.B. der -Benutername, seine ID und das Homeverzeichnis: +Benutzername, seine ID und das Homeverzeichnis: $ cut -d: -f1,3,6 /etc/passwd root:0:/root @@ -110,8 +119,7 @@ parlance, it projects a relation.'' [ XXX Cut fuehrt also die Datenbankoperation Projektion auf -Textdateien aus. Die Wikipedia erklaert das in -verstaendlicherer Sprache: +Textdateien aus. Die Wikipedia erklaert das folgendermassen: Die Projektion entspricht der Projektionsabbildung aus der Mengenlehre und kann auch Attributbeschränkung genannt @@ -137,7 +145,7 @@ gefunden. XXX mail an TUHS -Aber werfen wir doch einen Blick auf die BSD-Linie: Dort ist mein +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 @@ -157,9 +165,9 @@ erwaehnt bereits die erwartete Konformitaet mit POSIX.2. XXX 2 oder 3 modi? Nun sollte man wissen, dass POSIX.2 erst im September -1992 veroeffentlicht wurde, also gut zwei Jahren *nachdem* die +1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die Manpage und das Programm geschrieben wurden. Das Programm -wurde also anhand von Arbeitsversionen des Standards +wurde folglich anhand von Arbeitsversionen des Standards implementiert. Zweieinhalb Jahre Arbeit war immerhin schon in den Standardisierungsprozess geflossen; bis zur Fertigstellung sollte es aber noch weitere zwei Jahre dauern. @@ -167,8 +175,8 @@ Das cut der GNU Coreutils enthaelt einen Copyrightvermerk von David M. Ihnat aus dem Jahr 1984. -Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut -aus Sicht des urspruenglichen Unix zu den juengeren Tools. +Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut, +aus Sicht des urspruenglichen Unix, zu den juengeren Tools. Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist, so war Unix doch schon ueber zehn Jahre alt, als cut das erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht @@ -198,10 +206,10 @@ 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 denn den POSIX korrekt? +Welche Versionen implementieren POSIX korrekt? Die Situation ist dreiteilig: Es gibt traditionelle Implementierungen, die nur -c und -f kennen. Dann gibt es -Implementierungen die zwar -b kennen, es aber nur als Alias +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 @@ -212,7 +220,7 @@ Traditionelle Zwei-Modi-Implementierungen sind z.B. die von System III, System V und die aller BSDs bis in die 90er. -Pseude-Multibyte-Implementierungen bieten GNU und die +Pseudo-Multibyte-Implementierungen bieten GNU und die modernen NetBSDs und OpenBSDs. Wie sehr dort ein Schein von POSIX-Konformitaet gewahrt wird, ist unterschiedlich. Nicht immer findet man klare Aussagen wie diese: @@ -249,8 +257,8 @@ Zeilenumbruch fuegt echo(1) hinzu.) Mit dem Programm iconv(1) kann man Text explizit in bestimmte -Kodierungen konvertieren. Hier Beispiele, wie das Ergebnis -bei Latin1 und wie es bei UTF-8 aussieht. +Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe +bei Latin1 und wie sie bei UTF-8 aussieht. $ echo ä | iconv -t latin1 | od -c 0000000 344 \n @@ -266,21 +274,21 @@ Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System, dann sollte sich eine POSIX-konforme Implementierung so verhalten: - $ echo aä | ./cut -c -2 | od -c - 0000000 a 303 244 \n - 0000004 - - $ echo aä | ./cut -b -2 | od -c - 0000000 a 303 \n + $ echo ä | ./cut -c 1 | od -c + 0000000 303 244 \n 0000003 - $ echo aä | ./cut -b -2 -n | od -c - 0000000 a \n + $ echo ä | ./cut -b 1 | od -c + 0000000 303 \n 0000002 -Bei einer Implementierung, die -b und -c gleich behandelt, -ist die Ausgabe in allen drei Faellen wie die mittlere: Es -werden die ersten beiden Bytes ausgegeben. + $ echo ä | ./cut -b 1 -n | od -c + 0000000 \n + 0000001 + +Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in +allen drei Faellen wie die mittlere: Es wird das erste Byte +ausgegeben. Implementierungen @@ -330,7 +338,7 @@ 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 am +fast 40 nach oben. Dies liegt bei GNU 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 @@ -384,10 +392,9 @@ 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 7.0 cut out selected 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 -XXX FreeBSD 10 Heirloom Tools cut out selected fields of each line of a file Heirloom Tools (src) cut out fields of lines of files @@ -423,10 +430,10 @@ 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 etwas +Worte ``cut out'' sind vielleicht auch nur etwas zu missverstaendlich. HP-UX hat sie deshalb praezisiert. -Auch beim Begriff, was denn nun selektiert wird, ist man sich +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 (Research Unix). Ironischerweise leistet sich gerade Version @@ -443,5 +450,6 @@ Lizenz + CC0 (und kann damit auch unter CC BY-SA 4.0 Unported veroeffentlicht werden)