# HG changeset patch # User markus schnalke # Date 1432788068 -7200 # Node ID bac481be86d7c81794313f519b9d42aa6a7b27fd # Parent c0e589b92c52cf92cae20256e24f01f6004f65b2 Umlaute konvertiert diff -r c0e589b92c52 -r bac481be86d7 cut.txt --- a/cut.txt Thu May 28 06:34:21 2015 +0200 +++ b/cut.txt Thu May 28 06:41:08 2015 +0200 @@ -6,16 +6,16 @@ Cut ist ein klassisches Programm im Unix-Werkzeugkasten. In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt -es, denn es ist ein schoenes, praktisches und anschauliches +es, denn es ist ein schönes, praktisches und anschauliches Helferlein. Hier soll ein wenig hinter seine Fassade geschaut werden. Funktionsweise -Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten -erweitert wurden. Cut schneidet entweder gewuenschte Zeichen aus -den Zeilen der Eingabe oder gewuenschte, durch Trennzeichen +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. Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu @@ -35,24 +35,24 @@ $ ls -l | cut -c 3,6,9 ww- -Mit cut lassen sich aber auch Strings kuerzen. +Mit cut lassen sich aber auch Strings kürzen. $ long=12345678901234567890 $ echo "$long" | cut -c -10 1234567890 Dieser Befehl gibt die ersten maximal 10 Zeichen von -`$long' aus. (Alternativ kann man hierfuer `printf +`$long' aus. (Alternativ kann man hierfür `printf "%.10s\n" "$long"' verwenden.) Geht es aber nicht um die Darstellung von Zeichen, sondern um ihre Speicherung, dann ist `-c' nicht unbedingt geeignet. -Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung +Früher, als US-ASCII noch die omnipräsente Zeichenkodierung war, wurde jedes Zeichen mit genau einem -Byte gespeichert. Somit selektierte `cut -c' gleichermassen +Byte gespeichert. Somit selektierte `cut -c' gleichermaßen sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von -dieser Annahme loesen. In diesem Zug bekam cut mit +dieser Annahme lösen. In diesem Zug bekam cut mit POSIX.2-1992 einen Bytemodus (Option `-b'). Will man also nur die ersten maximal 500 Bytes vor dem Newline-Zeichen stehen haben (und den Rest stillschweigend @@ -61,11 +61,11 @@ $ cut -b -500 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese -Funktion ist insbesondere fuer POSIX wichtig, da man damit -Textdateien mit begrenzter Zeilenlaenge erzeugen kann. +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 -Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte +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 aber wurde eine neue Implementierungsweise gefordert. Das Problem @@ -74,11 +74,11 @@ 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. Es gilt in -gleicher Weise fuer die Eingabe und die Ausgabe. +können Felder ausgewählt werden. Das Trennzeichen (per +Default der Tab) kann mit `-d' geändert werden. Es gilt in +gleicher Weise für die Eingabe und die Ausgabe. -Der typische Anwendungsfall fuer cut im Feldmodus ist die +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: @@ -89,27 +89,27 @@ mail:8 ... -(Die Argumente fuer die Optionen koennen bei cut uebrigens -mit Whitespace abgetrennt oder direkt angehaengt folgen.) +(Die Argumente für die Optionen können bei cut übrigens +mit Whitespace abgetrennt oder direkt angehängt folgen.) -Dieser Feldmodus ist fuer einfache tabellarische Dateien, +Dieser Feldmodus ist für einfache tabellarische Dateien, wie eben die passwd, gut geeignet. Er kommt aber schnell an -seine Grenzen. Gerade der haeufige Fall, dass an Whitespace +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 fuehren zu einem leeren Feld. Dieses +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 gewuenschte Verhalten -fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn +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 -Faellen. +Fällen. Awk bietet noch eine weitere Funktion, die cut missen -laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei +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 @@ -121,8 +121,8 @@ 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 fuehrt demnach die Datenbankoperation Projektion auf -Textdateien aus. Die Wikipedia erklaert das folgendermassen: +Cut führt demnach die Datenbankoperation Projektion auf +Textdateien aus. Die Wikipedia erklärt das folgendermaßen: Die Projektion entspricht der Projektionsabbildung aus der Mengenlehre und kann auch Attributbeschränkung genannt @@ -137,28 +137,28 @@ Geschichtliches Cut erblickte 1982 mit dem Release von UNIX System III das -Licht der oeffentlichen Welt. Wenn man die Quellen von System +Licht der öffentlichen Welt. Wenn man die Quellen von System III durchforstet, findet man die Quellcodedatei cut.c mit dem 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 SCCS-ID im +Das ist die älteste Manifestation des Programms, die ich +aufstöbern konnte. Allerdings spricht die SCCS-ID im Quellcode von Version 1.5. Die Vorgeschichte liegt, der Aussage Doug McIlroys [ XXX -zufolge, in PWB/UNIX, das die Grundlage fuer System III war. +zufolge, in PWB/UNIX, das die Grundlage für System III war. (PWB 3.0 entspricht System III.) In den von PWB 1.0 (1977) -verfuegbaren Quellen +verfügbaren Quellen [ XXX ist cut noch nicht zu finden; von PWB 2.0 sind mir keine -verfuegbaren Quellen oder hilfreiche Dokumentation bekannt. +verfügbaren Quellen oder hilfreiche Dokumentation bekannt. -Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester +Nun ein Blick auf die BSD-Linie: Dort ist mein frühester 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 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. @@ -169,12 +169,12 @@ [ 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. +erwähnt bereits die erwartete Konformität mit POSIX.2. Nun muss man wissen, dass POSIX.2 erst im September -1992 veroeffentlicht wurde, erst gut zwei Jahren nachdem die +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 bekraeftigt diese Vermutung. +implementiert. Ein Blick in den Code bekräftigt diese Vermutung. In der Funktion zum parsen der Feldauswahlliste findet sich dieser Kommentar: @@ -182,61 +182,61 @@ POSIX doesn't allow lists that aren't in increasing order or overlapping lists. -Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits +Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits ein: The elements in list can be repeated, can overlap, and can be specified in any order. -Zudem listet Draft 11.2 alle drei Modi, waehrend in diesem -BSD cut nur die zwei alten implementiert sind. Es koennte also +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. Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir -leider nicht moeglich, diese Vermutung zu pruefen. +leider nicht möglich, diese Vermutung zu prüfen. -Die Versionsnummern und Aenderungsdaten der aelteren +Die Versionsnummern und Änderungsdaten der älteren BSD-Implementierungen kann man aus den SCCS-IDs, die vom -damaligen Versionskontrollsystem in den Code eingefuegt wurden, +damaligen Versionskontrollsystem in den Code eingefügt wurden, ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. -Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk: +Das cut der GNU Coreutils enthält folgenden Copyrightvermerk: Copyright (C) 1997-2015 Free Software Foundation, Inc. Copyright (C) 1984 David M. Ihnat -Der Code hat also recht alte Urspruenge. Wie aus weiteren +Der Code hat also recht alte Ursprünge. Wie aus weiteren Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David -MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer +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. -Trotz der vielen 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 noch nicht +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 doch 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 schon vertreten. Man muss sich also -fragen, warum cut ueberhaupt noch entwickelt wurde, wo es +fragen, warum cut überhaupt noch entwickelt wurde, wo es 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 +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 ueberzeugte. Es wurde in andere Unix Varianten uebernommen, -standardisiert und ist heutzutage ueberall anzutreffen. +Cut überzeugte. Es wurde in andere Unix Varianten übernommen, +standardisiert und ist heutzutage überall anzutreffen. -Die urspruengliche Variante (ohne -b) wurde schon 1985 in +Die ursprüngliche Variante (ohne -b) wurde schon 1985 in der System V Interface Definition, einer wichtigen formalen Beschreibung von UNIX System V, spezifiziert und tauchte -anschliessend in allen relevanten Standards auf. Mit POSIX.2 +anschließend in allen relevanten Standards auf. Mit POSIX.2 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form (mit -b) standardisiert. -Multibyte-Unterstuetzung +Multibyte-Unterstützung Nun sind der Bytemodus und die damit verbundene Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit @@ -245,11 +245,11 @@ 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 +für -c handhaben. Diese Implementierungen funktionieren mit Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei -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 +Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber +wie -b (und -n wird ignoriert). Schließlich gibt es noch +Implementierungen, die -b und -c tatsächlich POSIX-konform implementieren. Historische Zwei-Modi-Implementierungen sind z.B. die von @@ -257,11 +257,11 @@ Pseudo-Multibyte-Implementierungen bieten GNU und die modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen, -ob dort ein Schein von POSIX-Konformitaet gewahrt wird. +ob dort ein Schein von POSIX-Konformität gewahrt wird. Teilweise findet man erst nach genauerer Suche heraus, dass -c und -n nicht wie erwartet funktionieren; teilweise machen es sich die Systeme auch einfach, indem sie auf -Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist +Singlebyte-Zeichenkodierungen beharren, das aber dafür meist klar darlegen: Since we don't support multi-byte characters, the -c and -b @@ -269,20 +269,20 @@ [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup -Tatsaechlich standardkonforme Implementierungen, die +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 grossen BSDs diese Aenderung nicht -uebernommen haben, bleibt offen. Es scheint aber an der im +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. Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen -Systems Multibytes korrekt unterstuetzt werden? Zuerst ist +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 eruebrigt sich. Man kann das +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 @@ -293,7 +293,7 @@ 0000003 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den -Zeilenumbruch fuegt echo(1) hinzu.) +Zeilenumbruch fügt echo(1) hinzu.) Mit dem Programm iconv(1) kann man Text explizit in bestimmte Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe @@ -311,7 +311,7 @@ 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 folgendermassen +dann sollte sich eine POSIX-konforme Implementierung folgendermaßen verhalten: $ echo ä | cut -c 1 | od -c @@ -327,7 +327,7 @@ 0000001 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in -allen drei Faellen wie die mittlere: Es wird das erste Byte +allen drei Fällen wie die mittlere: Es wird das erste Byte ausgegeben. @@ -336,15 +336,15 @@ Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an Implementierungen. -Fuer einen ersten Eindruck ist der Umfang des Quellcodes -hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese +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, -bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus -erfordert zwangslaeufig mehr Code, deshalb sind diese +bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus +erfordert zwangsläufig mehr Code, deshalb sind diese Implementierungen tendenziell umfangreicher. - SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie + SLOC Zeilen Bytes Gehört zu Dateidatum Kategorie ----------------------------------------------------------------- 116 123 2966 System III 1980-04-11 (hist) 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist) @@ -360,56 +360,60 @@ Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei -urspruenglichen Implementierungen, die sich nur minimal -unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit +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-390 SLOCs. Und schliesslich (4) die +die alte GNU-Version mit 340-390 SLOCs. Und schließlich (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 --l') erstreckt sich ueber eine Spanne von Faktor 1.06 bei den -aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Den groessten +SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (`wc +-l') 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 Groesse des Lizenzblocks am Dateianfang. +die Größe des Lizenzblocks am Dateianfang. Betrachtet man die Abweichungen zwischen den logischen Codezeilen -und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld +und der Dateigröße (`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. Bei GNU liegt dies hauptsaechlich an deren -Programmierstil, mit spezieller Einrueckung und langen Bezeichnern. -Ob man die Heirloom-Implementierung als besonders kryptisch +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 +[ XXX +als besonders kryptisch oder als besonders elegant bezeichnen will, das soll der -eigenen Einschaetzung des Lesers ueberlassen bleiben. Vor allem -der Vergleich mit einer GNU-Implementierung ist eindrucksvoll. +eigenen Einschätzung des Lesers überlassen bleiben. Vor allem +der Vergleich mit einer GNU-Implementierung +[ XXX +ist eindrucksvoll. -Die interne Struktur der Programmcodes (in C) ist meist aehnlich. +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 ueberfuehrt. Desweiteren -haben fast alle Implementierungen separate Funktionen fuer die +Feldauswahl in eine interne Datenstruktur überführt. Desweiteren +haben fast alle Implementierungen separate Funktionen für die zwei oder drei Modi. Bei den POSIX-konformen Implementierungen wird die `-b -n'-Kombination als weiterer Modus behandelt, und -damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen +damit in einer eigenen Funktion umgesetzt. Nur bei der frühen System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) -wird ausser den Fehlerausgaben alles in der main-Funktion +wird außer 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 sind beide Groessen auf 512 begrenzt. +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 (_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 dafuer wird +Zeilenlänge beliebig groß werden; der Speicher dafür wird dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer -Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die +Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die begrenzte Felderanzahl scheint jedoch kein Praxisproblem darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus -gross genug sein sollte. +groß genug sein sollte. Beschreibungen @@ -448,44 +452,44 @@ Die mit ``(src)'' markierten Beschreibungen sind aus dem -jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt +jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält die Beschreibung im Standard. Der ``Unix Reader'' ist ein -rueckblickendes Textdokument von Doug McIlroy, das das +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 koennte ein Uebertragungsfehler -oder eine nachtraegliche Korrektur sein. Alle uebrigen +entsprechen. Die Abweichung könnte ein Übertragungsfehler +oder eine nachträgliche Korrektur sein. Alle übrigen Beschreibungen entstammen den Manpages. -Oft ist mit der Zeit die POSIX-Beschreibung uebernommen +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 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 zu missverstaendlich. -HP-UX hat sie deshalb praezisiert. +Kommandozeilenangabe klar ein Auswählen darstellt. Die +Worte ``cut out'' sind vielleicht auch zu missverständlich. +HP-UX hat sie deshalb präzisiert. 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). Ironischerweise leistet sich gerade Version 8 Unix, das eigentlich um eine sehr treffende Weltsicht -bemueht ist, mit ``rearrange columns of data'' die +bemüht ist, mit ``rearrange columns of data'' die unzutreffendste der Beschreibungen. Autoreninfo -Markus Schnalke interessiert sich fuer die Hintergruende -von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses +Markus Schnalke interessiert sich für die Hintergründe +von Unix und seinen Werkzeugen. Für die Erarbeitung dieses Textes wurde er regelrecht zum Historiker. Lizenz CC0 (und kann damit auch unter CC BY-SA 4.0 Unported -veroeffentlicht werden) +veröffentlicht werden)