# HG changeset patch # User markus schnalke # Date 1431408933 -7200 # Node ID 77d1f55bba08a7166c12538f2a49e58ea43ef11c # Parent 21ad1c1548c45ee743c1245000fa3ad13947bc50 Weitere Ueberarbeitungen diff -r 21ad1c1548c4 -r 77d1f55bba08 cut.txt --- a/cut.txt Tue May 12 06:46:59 2015 +0200 +++ b/cut.txt Tue May 12 07:35:33 2015 +0200 @@ -1,5 +1,3 @@ -Das Werkzeugkaestle, #1 - cut - cut out selected fields of each line of a file ---------------------------------------------------- markus schnalke @@ -25,6 +23,9 @@ Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in diesem Beispiel die Rechte des Besitzers: + $ ls -l foo + -rw-rw-r-- 1 meillo users 0 May 12 07:32 foo + $ ls -l foo | cut -c 2-4 rw- @@ -41,7 +42,7 @@ 1234567890 Dieser Befehl gibt die ersten maximal 10 Zeichen von -`$long' aus. (Alternativ kann man hierfuer auch `printf +`$long' aus. (Alternativ kann man hierfuer `printf "%.10s\n" "$long"' verwenden.) Geht es aber nicht um die Darstellung von Zeichen, sondern um @@ -109,16 +110,7 @@ Awk bietet noch eine weitere Funktion, die cut missen laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein -Feld kann selbst mehrfach angegeben werden. - -XXX -4.3BSD-Reno + *BSDs - * 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. We also handle "-3-5" although there's no - * real reason too. - -So gibt der Aufruf +Feld kann selbst mehrfach angegeben werden. So gibt der Aufruf von `cut -c 5-8,1,4-6' 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 @@ -172,31 +164,29 @@ 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? +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 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die Manpage und das Programm geschrieben wurden. Das Programm 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. +implementiert. Ein Blick in den Code bekraeftigt diese Vermutung. +In der Funktion zum parsen der Feldauswahlliste findet sich +dieser Kommentar: -XXX -Schaut man sich die SCCS-IDs (die vom damaligen -Versionskontrollsystem eingefuegt wurden) in den BSD-Quellen an, -dann findet man dort Versionsnummern, die die Entstehung -dokumentieren: + 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. - 4.3BSD-UWisc "@(#)cut.c 1.3"; - 4.3BSD-Reno "@(#)cut.c 5.3 (Berkeley) 6/24/90"; - NetBSD "@(#)cut.c 5.4 (Berkeley) 10/30/90"; - FreeBSD "@(#)cut.c 8.1 (Berkeley) 6/6/93"; +Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits +ein: -Die neueren BSD-Versionen enthalten zwar weiterhin eine SCCS-ID, diese -ist aber bei Version "8.3 (Berkeley) 5/4/95" stehen geblieben. Danach -wurde scheinbar von SCCS auf ein anderes -Versionskontrollsystem gewechselt. -XXX + 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) +ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk: @@ -233,7 +223,7 @@ anschliessend in allen relevanten Standards auf. Mit POSIX.2 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form (mit -b) standardisiert. -XXX sicher? s.o. +XXX sicher? Multibyte-Unterstuetzung @@ -256,14 +246,18 @@ System III, System V und die aller BSDs bis in die 90er. 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: +modernen NetBSDs und OpenBSDs. Man darf sich durchaus 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: - /* Since we don't support multi-byte characters, the -c and -b - options are equivalent, and the -n option is meaningless. */ + Since we don't support multi-byte characters, the -c and -b + options are equivalent, and the -n option is meaningless. -[ XXX +[ openbsd XXX Tatsaechlich standardkonforme Implementierungen, die Multibytes korrekt handhaben, bekommt man bei einem modernen @@ -392,16 +386,20 @@ wird ausser den Fehlerausgaben nichts aus der main-Funktion ausgelagert. -XXX -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 +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 (fgetln). XXX +beliebiger Zeilenlaenge. XXX fgetln +Die begrenzte Felderanzahl scheint jedeoch kein praktisches +Problem darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 +durchaus genug Platz bieten sollte. Beschreibungen