comparison cut.txt @ 21:bac481be86d7

Umlaute konvertiert
author markus schnalke <meillo@marmaro.de>
date Thu, 28 May 2015 06:41:08 +0200
parents c0e589b92c52
children 4193939c6a24
comparison
equal deleted inserted replaced
20:c0e589b92c52 21:bac481be86d7
4 2015-05 4 2015-05
5 5
6 6
7 Cut ist ein klassisches Programm im Unix-Werkzeugkasten. 7 Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
8 In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt 8 In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
9 es, denn es ist ein schoenes, praktisches und anschauliches 9 es, denn es ist ein schönes, praktisches und anschauliches
10 Helferlein. Hier soll ein wenig hinter seine Fassade geschaut 10 Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
11 werden. 11 werden.
12 12
13 13
14 Funktionsweise 14 Funktionsweise
15 15
16 Urspruenglich hatte cut zwei Modi, die spaeter um einen dritten 16 Ursprünglich hatte cut zwei Modi, die später um einen dritten
17 erweitert wurden. Cut schneidet entweder gewuenschte Zeichen aus 17 erweitert wurden. Cut schneidet entweder gewünschte Zeichen aus
18 den Zeilen der Eingabe oder gewuenschte, durch Trennzeichen 18 den Zeilen der Eingabe oder gewünschte, durch Trennzeichen
19 definierte, Felder. 19 definierte, Felder.
20 20
21 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu 21 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
22 zerteilen. Man kann damit beispielsweise bestimmte 22 zerteilen. Man kann damit beispielsweise bestimmte
23 Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in 23 Zugriffsrechte aus der Ausgabe von `ls -l' ausschneiden, in
33 Welt: 33 Welt:
34 34
35 $ ls -l | cut -c 3,6,9 35 $ ls -l | cut -c 3,6,9
36 ww- 36 ww-
37 37
38 Mit cut lassen sich aber auch Strings kuerzen. 38 Mit cut lassen sich aber auch Strings kürzen.
39 39
40 $ long=12345678901234567890 40 $ long=12345678901234567890
41 $ echo "$long" | cut -c -10 41 $ echo "$long" | cut -c -10
42 1234567890 42 1234567890
43 43
44 Dieser Befehl gibt die ersten maximal 10 Zeichen von 44 Dieser Befehl gibt die ersten maximal 10 Zeichen von
45 `$long' aus. (Alternativ kann man hierfuer `printf 45 `$long' aus. (Alternativ kann man hierfür `printf
46 "%.10s\n" "$long"' verwenden.) 46 "%.10s\n" "$long"' verwenden.)
47 47
48 Geht es aber nicht um die Darstellung von Zeichen, sondern um 48 Geht es aber nicht um die Darstellung von Zeichen, sondern um
49 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet. 49 ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
50 Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung 50 Früher, als US-ASCII noch die omnipräsente Zeichenkodierung
51 war, wurde jedes Zeichen mit genau einem 51 war, wurde jedes Zeichen mit genau einem
52 Byte gespeichert. Somit selektierte `cut -c' gleichermassen 52 Byte gespeichert. Somit selektierte `cut -c' gleichermaßen
53 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von 53 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
54 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von 54 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
55 dieser Annahme loesen. In diesem Zug bekam cut mit 55 dieser Annahme lösen. In diesem Zug bekam cut mit
56 POSIX.2-1992 einen Bytemodus (Option `-b'). Will man 56 POSIX.2-1992 einen Bytemodus (Option `-b'). Will man
57 also nur die ersten maximal 500 Bytes vor dem 57 also nur die ersten maximal 500 Bytes vor dem
58 Newline-Zeichen stehen haben (und den Rest stillschweigend 58 Newline-Zeichen stehen haben (und den Rest stillschweigend
59 ignorieren), dann macht man das mit: 59 ignorieren), dann macht man das mit:
60 60
61 $ cut -b -500 61 $ cut -b -500
62 62
63 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese 63 Den Rest kann man sich mit `cut -b 501-' einfangen. Diese
64 Funktion ist insbesondere fuer POSIX wichtig, da man damit 64 Funktion ist insbesondere für POSIX wichtig, da man damit
65 Textdateien mit begrenzter Zeilenlaenge erzeugen kann. 65 Textdateien mit begrenzter Zeilenlänge erzeugen kann.
66 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 66 [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
67 67
68 Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte 68 Wenn auch der Bytemodus neu eingeführt worden war, so sollte
69 er sich doch nur so verhalten wie der alte Zeichenmodus 69 er sich doch nur so verhalten wie der alte Zeichenmodus
70 normalerweise schon implementiert war. Beim Zeichenmodus aber 70 normalerweise schon implementiert war. Beim Zeichenmodus aber
71 wurde eine neue Implementierungsweise gefordert. Das Problem 71 wurde eine neue Implementierungsweise gefordert. Das Problem
72 war folglich nicht, den neuen Bytemodus zu implementieren, sondern 72 war folglich nicht, den neuen Bytemodus zu implementieren, sondern
73 den Zeichenmodus neu zu implementieren. 73 den Zeichenmodus neu zu implementieren.
74 74
75 Neben dem Zeichen- und Bytemodus bietet cut noch den 75 Neben dem Zeichen- und Bytemodus bietet cut noch den
76 Feldmodus, den man mit `-f' einleitet. Mit ihm 76 Feldmodus, den man mit `-f' einleitet. Mit ihm
77 koennen Felder ausgewaehlt werden. Das Trennzeichen (per 77 können Felder ausgewählt werden. Das Trennzeichen (per
78 Default der Tab) kann mit `-d' geaendert werden. Es gilt in 78 Default der Tab) kann mit `-d' geändert werden. Es gilt in
79 gleicher Weise fuer die Eingabe und die Ausgabe. 79 gleicher Weise für die Eingabe und die Ausgabe.
80 80
81 Der typische Anwendungsfall fuer cut im Feldmodus ist die 81 Der typische Anwendungsfall für cut im Feldmodus ist die
82 Auswahl von Information aus der passwd-Datei. Hier z.B. der 82 Auswahl von Information aus der passwd-Datei. Hier z.B. der
83 Benutzername und seine ID: 83 Benutzername und seine ID:
84 84
85 $ cut -d: -f1,3 /etc/passwd 85 $ cut -d: -f1,3 /etc/passwd
86 root:0 86 root:0
87 bin:1 87 bin:1
88 daemon:2 88 daemon:2
89 mail:8 89 mail:8
90 ... 90 ...
91 91
92 (Die Argumente fuer die Optionen koennen bei cut uebrigens 92 (Die Argumente für die Optionen können bei cut übrigens
93 mit Whitespace abgetrennt oder direkt angehaengt folgen.) 93 mit Whitespace abgetrennt oder direkt angehängt folgen.)
94 94
95 Dieser Feldmodus ist fuer einfache tabellarische Dateien, 95 Dieser Feldmodus ist für einfache tabellarische Dateien,
96 wie eben die passwd, gut geeignet. Er kommt aber schnell an 96 wie eben die passwd, gut geeignet. Er kommt aber schnell an
97 seine Grenzen. Gerade der haeufige Fall, dass an Whitespace 97 seine Grenzen. Gerade der häufige Fall, dass an Whitespace
98 in Felder geteilt werden soll, wird damit nicht abgedeckt. 98 in Felder geteilt werden soll, wird damit nicht abgedeckt.
99 Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann 99 Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
100 demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt 100 demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
101 werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander 101 werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander
102 stehende Trennzeichen fuehren zu einem leeren Feld. Dieses 102 stehende Trennzeichen führen zu einem leeren Feld. Dieses
103 Verhalten widerspricht den Erwartungen, die man an die 103 Verhalten widerspricht den Erwartungen, die man an die
104 Verarbeitung einer Datei mit Whitespace-getrennten Feldern 104 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
105 hat. Manche Implementierungen von cut, z.B. die von FreeBSD, 105 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
106 haben deshalb Erweiterungen, die das gewuenschte Verhalten 106 haben deshalb Erweiterungen, die das gewünschte Verhalten
107 fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn 107 für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
108 man portabel bleiben will, verwendet man awk in diesen 108 man portabel bleiben will, verwendet man awk in diesen
109 Faellen. 109 Fällen.
110 110
111 Awk bietet noch eine weitere Funktion, die cut missen 111 Awk bietet noch eine weitere Funktion, die cut missen
112 laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei 112 lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
113 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein 113 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
114 Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt 114 Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt
115 der Aufruf 115 der Aufruf
116 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8 116 von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
117 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit 117 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
119 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind 119 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
120 hierbei immer gleich geordnet wie in der Eingabe. Um die Worte 120 hierbei immer gleich geordnet wie in der Eingabe. Um die Worte
121 der Manpage von Version 8 Unix wiederzugeben: ``In data base 121 der Manpage von Version 8 Unix wiederzugeben: ``In data base
122 parlance, it projects a relation.'' 122 parlance, it projects a relation.''
123 [ http://man.cat-v.org/unix_8th/1/cut 123 [ http://man.cat-v.org/unix_8th/1/cut
124 Cut fuehrt demnach die Datenbankoperation Projektion auf 124 Cut führt demnach die Datenbankoperation Projektion auf
125 Textdateien aus. Die Wikipedia erklaert das folgendermassen: 125 Textdateien aus. Die Wikipedia erklärt das folgendermaßen:
126 126
127 Die Projektion entspricht der Projektionsabbildung aus der 127 Die Projektion entspricht der Projektionsabbildung aus der
128 Mengenlehre und kann auch Attributbeschränkung genannt 128 Mengenlehre und kann auch Attributbeschränkung genannt
129 werden. Sie extrahiert einzelne Attribute aus der 129 werden. Sie extrahiert einzelne Attribute aus der
130 ursprünglichen Attributmenge und ist somit als eine Art 130 ursprünglichen Attributmenge und ist somit als eine Art
135 135
136 136
137 Geschichtliches 137 Geschichtliches
138 138
139 Cut erblickte 1982 mit dem Release von UNIX System III das 139 Cut erblickte 1982 mit dem Release von UNIX System III das
140 Licht der oeffentlichen Welt. Wenn man die Quellen von System 140 Licht der öffentlichen Welt. Wenn man die Quellen von System
141 III durchforstet, findet man die Quellcodedatei cut.c mit dem 141 III durchforstet, findet man die Quellcodedatei cut.c mit dem
142 Zeitstempel 1980-04-11. 142 Zeitstempel 1980-04-11.
143 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd 143 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
144 Das ist die aelteste Manifestation des Programms, die ich 144 Das ist die älteste Manifestation des Programms, die ich
145 aufstoebern konnte. Allerdings spricht die SCCS-ID im 145 aufstöbern konnte. Allerdings spricht die SCCS-ID im
146 Quellcode von Version 1.5. Die Vorgeschichte liegt, der Aussage 146 Quellcode von Version 1.5. Die Vorgeschichte liegt, der Aussage
147 Doug McIlroys 147 Doug McIlroys
148 [ XXX 148 [ XXX
149 zufolge, in PWB/UNIX, das die Grundlage fuer System III war. 149 zufolge, in PWB/UNIX, das die Grundlage für System III war.
150 (PWB 3.0 entspricht System III.) In den von PWB 1.0 (1977) 150 (PWB 3.0 entspricht System III.) In den von PWB 1.0 (1977)
151 verfuegbaren Quellen 151 verfügbaren Quellen
152 [ XXX 152 [ XXX
153 ist cut noch nicht zu finden; von PWB 2.0 sind mir keine 153 ist cut noch nicht zu finden; von PWB 2.0 sind mir keine
154 verfuegbaren Quellen oder hilfreiche Dokumentation bekannt. 154 verfügbaren Quellen oder hilfreiche Dokumentation bekannt.
155 155
156 Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester 156 Nun ein Blick auf die BSD-Linie: Dort ist mein frühester
157 Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07 157 Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
158 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut 158 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
159 als Teil der Spezialversion 4.3BSD-UWisc, 159 als Teil der Spezialversion 4.3BSD-UWisc,
160 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix 160 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
161 die im Januar 1987 veroeffentlicht wurde. 161 die im Januar 1987 veröffentlicht wurde.
162 Die Implementierung unterscheidet sich nur minimal von der 162 Die Implementierung unterscheidet sich nur minimal von der
163 in System III. 163 in System III.
164 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf. 164 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
165 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder 165 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
166 ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und 166 ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
167 Marciano Pitargue neu implementiertes cut, das 1989 in BSD 167 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
168 aufgenommen wurde. 168 aufgenommen wurde.
169 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut 169 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
170 Seine Manpage 170 Seine Manpage
171 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1 171 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
172 erwaehnt bereits die erwartete Konformitaet mit POSIX.2. 172 erwähnt bereits die erwartete Konformität mit POSIX.2.
173 Nun muss man wissen, dass POSIX.2 erst im September 173 Nun muss man wissen, dass POSIX.2 erst im September
174 1992 veroeffentlicht wurde, erst gut zwei Jahren nachdem die 174 1992 veröffentlicht wurde, erst gut zwei Jahren nachdem die
175 Manpage und das Programm geschrieben worden waren. Das Programm 175 Manpage und das Programm geschrieben worden waren. Das Programm
176 wurde folglich anhand von Arbeitsversionen des Standards 176 wurde folglich anhand von Arbeitsversionen des Standards
177 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung. 177 implementiert. Ein Blick in den Code bekräftigt diese Vermutung.
178 In der Funktion zum parsen der Feldauswahlliste findet sich 178 In der Funktion zum parsen der Feldauswahlliste findet sich
179 dieser Kommentar: 179 dieser Kommentar:
180 180
181 This parser is less restrictive than the Draft 9 POSIX spec. 181 This parser is less restrictive than the Draft 9 POSIX spec.
182 POSIX doesn't allow lists that aren't in increasing order or 182 POSIX doesn't allow lists that aren't in increasing order or
183 overlapping lists. 183 overlapping lists.
184 184
185 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilitaet bereits 185 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits
186 ein: 186 ein:
187 187
188 The elements in list can be repeated, can overlap, and can 188 The elements in list can be repeated, can overlap, and can
189 be specified in any order. 189 be specified in any order.
190 190
191 Zudem listet Draft 11.2 alle drei Modi, waehrend in diesem 191 Zudem listet Draft 11.2 alle drei Modi, während in diesem
192 BSD cut nur die zwei alten implementiert sind. Es koennte also 192 BSD cut nur die zwei alten implementiert sind. Es könnte also
193 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war. 193 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
194 Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir 194 Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
195 leider nicht moeglich, diese Vermutung zu pruefen. 195 leider nicht möglich, diese Vermutung zu prüfen.
196 196
197 Die Versionsnummern und Aenderungsdaten der aelteren 197 Die Versionsnummern und Änderungsdaten der älteren
198 BSD-Implementierungen kann man aus den SCCS-IDs, die vom 198 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
199 damaligen Versionskontrollsystem in den Code eingefuegt wurden, 199 damaligen Versionskontrollsystem in den Code eingefügt wurden,
200 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. 200 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
201 201
202 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk: 202 Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:
203 203
204 Copyright (C) 1997-2015 Free Software Foundation, Inc. 204 Copyright (C) 1997-2015 Free Software Foundation, Inc.
205 Copyright (C) 1984 David M. Ihnat 205 Copyright (C) 1984 David M. Ihnat
206 206
207 Der Code hat also recht alte Urspruenge. Wie aus weiteren 207 Der Code hat also recht alte Ursprünge. Wie aus weiteren
208 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David 208 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
209 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer 209 MacKenzie und später von Jim Meyering überarbeitet. Letzterer
210 hat den Code 1992 auch ins Versionkontrollsystem eingestellt. 210 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
211 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im 211 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
212 Copyright-Vermerk auftauchen, ist unklar. 212 Copyright-Vermerk auftauchen, ist unklar.
213 213
214 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut, 214 Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut,
215 aus Sicht des urspruenglichen Unix, zu den juengeren Tools. 215 aus Sicht des ursprünglichen Unix, zu den jüngeren Tools.
216 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist, 216 Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist,
217 so war Unix doch schon ueber zehn Jahre alt, als cut das 217 so war Unix doch schon über zehn Jahre alt, als cut das
218 erste Mal auftauchte. Insbesondere gehoerte cut noch nicht 218 erste Mal auftauchte. Insbesondere gehörte cut noch nicht
219 zu Version 7 Unix, das die Ausgangsbasis aller modernen 219 zu Version 7 Unix, das die Ausgangsbasis aller modernen
220 Unix-Systeme darstellt. Die weit komplexeren Programme sed 220 Unix-Systeme darstellt. Die weit komplexeren Programme sed
221 und awk waren dort schon vertreten. Man muss sich also 221 und awk waren dort schon vertreten. Man muss sich also
222 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es 222 fragen, warum cut überhaupt noch entwickelt wurde, wo es
223 schon zwei Programme gab, die die Funktion von cut abdecken 223 schon zwei Programme gab, die die Funktion von cut abdecken
224 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und 224 konnten. Ein Argument für cut war sicher seine Kompaktheit und
225 die damit verbundene Geschwindigkeit gegenueber dem damals 225 die damit verbundene Geschwindigkeit gegenüber dem damals
226 traegen awk. Diese schlanke Gestalt ist es auch, die der 226 trägen awk. Diese schlanke Gestalt ist es auch, die der
227 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig! 227 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
228 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen, 228 Cut überzeugte. Es wurde in andere Unix Varianten übernommen,
229 standardisiert und ist heutzutage ueberall anzutreffen. 229 standardisiert und ist heutzutage überall anzutreffen.
230 230
231 Die urspruengliche Variante (ohne -b) wurde schon 1985 in 231 Die ursprüngliche Variante (ohne -b) wurde schon 1985 in
232 der System V Interface Definition, einer wichtigen formalen 232 der System V Interface Definition, einer wichtigen formalen
233 Beschreibung von UNIX System V, spezifiziert und tauchte 233 Beschreibung von UNIX System V, spezifiziert und tauchte
234 anschliessend in allen relevanten Standards auf. Mit POSIX.2 234 anschließend in allen relevanten Standards auf. Mit POSIX.2
235 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form 235 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
236 (mit -b) standardisiert. 236 (mit -b) standardisiert.
237 237
238 238
239 Multibyte-Unterstuetzung 239 Multibyte-Unterstützung
240 240
241 Nun sind der Bytemodus und die damit verbundene 241 Nun sind der Bytemodus und die damit verbundene
242 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit 242 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
243 1992 standardisiert, wie steht es aber mit deren Umsetzung? 243 1992 standardisiert, wie steht es aber mit deren Umsetzung?
244 Welche Versionen implementieren POSIX korrekt? 244 Welche Versionen implementieren POSIX korrekt?
245 Die Situation ist dreiteilig: Es gibt historische 245 Die Situation ist dreiteilig: Es gibt historische
246 Implementierungen, die nur -c und -f kennen. Dann gibt es 246 Implementierungen, die nur -c und -f kennen. Dann gibt es
247 Implementierungen die -b zwar kennen, es aber lediglich als Alias 247 Implementierungen die -b zwar kennen, es aber lediglich als Alias
248 fuer -c handhaben. Diese Implementierungen funktionieren mit 248 für -c handhaben. Diese Implementierungen funktionieren mit
249 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei 249 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
250 Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber 250 Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber
251 wie -b (und -n wird ignoriert). Schliesslich gibt es noch 251 wie -b (und -n wird ignoriert). Schließlich gibt es noch
252 Implementierungen, die -b und -c tatsaechlich POSIX-konform 252 Implementierungen, die -b und -c tatsächlich POSIX-konform
253 implementieren. 253 implementieren.
254 254
255 Historische Zwei-Modi-Implementierungen sind z.B. die von 255 Historische Zwei-Modi-Implementierungen sind z.B. die von
256 System III, System V und die aller BSDs bis in die 90er. 256 System III, System V und die aller BSDs bis in die 90er.
257 257
258 Pseudo-Multibyte-Implementierungen bieten GNU und die 258 Pseudo-Multibyte-Implementierungen bieten GNU und die
259 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen, 259 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
260 ob dort ein Schein von POSIX-Konformitaet gewahrt wird. 260 ob dort ein Schein von POSIX-Konformität gewahrt wird.
261 Teilweise findet man erst nach genauerer Suche heraus, dass 261 Teilweise findet man erst nach genauerer Suche heraus, dass
262 -c und -n nicht wie erwartet funktionieren; teilweise machen es 262 -c und -n nicht wie erwartet funktionieren; teilweise machen es
263 sich die Systeme auch einfach, indem sie auf 263 sich die Systeme auch einfach, indem sie auf
264 Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist 264 Singlebyte-Zeichenkodierungen beharren, das aber dafür meist
265 klar darlegen: 265 klar darlegen:
266 266
267 Since we don't support multi-byte characters, the -c and -b 267 Since we don't support multi-byte characters, the -c and -b
268 options are equivalent, and the -n option is meaningless. 268 options are equivalent, and the -n option is meaningless.
269 269
270 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup 270 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
271 271
272 Tatsaechlich standardkonforme Implementierungen, die 272 Tatsächlich standardkonforme Implementierungen, die
273 Multibytes korrekt handhaben, bekommt man bei einem modernen 273 Multibytes korrekt handhaben, bekommt man bei einem modernen
274 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins 274 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
275 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert. 275 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert.
276 [ https://svnweb.freebsd.org/base?view=revision&revision=131194 276 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
277 Warum die beiden anderen grossen BSDs diese Aenderung nicht 277 Warum die beiden anderen großen BSDs diese Änderung nicht
278 uebernommen haben, bleibt offen. Es scheint aber an der im 278 übernommen haben, bleibt offen. Es scheint aber an der im
279 obigen Kommentar formulierten Grundausrichtung zu liegen. 279 obigen Kommentar formulierten Grundausrichtung zu liegen.
280 280
281 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen 281 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
282 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist 282 Systems Multibytes korrekt unterstützt werden? Zuerst ist
283 entscheidend, ob das System selbst mit einem Multibyte-Encoding 283 entscheidend, ob das System selbst mit einem Multibyte-Encoding
284 arbeitet, denn tut es das nicht, dann entsprechen sich 284 arbeitet, denn tut es das nicht, dann entsprechen sich
285 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das 285 Zeichen und Bytes und die Frage erübrigt sich. Man kann das
286 herausfinden indem man sich das Locale anschaut, aber einfacher 286 herausfinden indem man sich das Locale anschaut, aber einfacher
287 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut, 287 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
288 auszugeben und zu schauen ob dieses in einem oder in mehreren 288 auszugeben und zu schauen ob dieses in einem oder in mehreren
289 Bytes kodiert ist: 289 Bytes kodiert ist:
290 290
291 $ echo ä | od -c 291 $ echo ä | od -c
292 0000000 303 244 \n 292 0000000 303 244 \n
293 0000003 293 0000003
294 294
295 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den 295 In diesem Fall sind es zwei Bytes: oktal 303 und 244 . (Den
296 Zeilenumbruch fuegt echo(1) hinzu.) 296 Zeilenumbruch fügt echo(1) hinzu.)
297 297
298 Mit dem Programm iconv(1) kann man Text explizit in bestimmte 298 Mit dem Programm iconv(1) kann man Text explizit in bestimmte
299 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe 299 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
300 bei Latin1 und wie sie bei UTF-8 aussieht. 300 bei Latin1 und wie sie bei UTF-8 aussieht.
301 301
309 309
310 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung) 310 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
311 wird recht sicher einer dieser beiden Ausgaben entsprechen. 311 wird recht sicher einer dieser beiden Ausgaben entsprechen.
312 312
313 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System, 313 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
314 dann sollte sich eine POSIX-konforme Implementierung folgendermassen 314 dann sollte sich eine POSIX-konforme Implementierung folgendermaßen
315 verhalten: 315 verhalten:
316 316
317 $ echo ä | cut -c 1 | od -c 317 $ echo ä | cut -c 1 | od -c
318 0000000 303 244 \n 318 0000000 303 244 \n
319 0000003 319 0000003
325 $ echo ä | cut -b 1 -n | od -c 325 $ echo ä | cut -b 1 -n | od -c
326 0000000 \n 326 0000000 \n
327 0000001 327 0000001
328 328
329 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in 329 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
330 allen drei Faellen wie die mittlere: Es wird das erste Byte 330 allen drei Fällen wie die mittlere: Es wird das erste Byte
331 ausgegeben. 331 ausgegeben.
332 332
333 333
334 Implementierungen 334 Implementierungen
335 335
336 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an 336 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
337 Implementierungen. 337 Implementierungen.
338 338
339 Fuer einen ersten Eindruck ist der Umfang des Quellcodes 339 Für einen ersten Eindruck ist der Umfang des Quellcodes
340 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese 340 hilfreich. Typischerweise steigt dieser über die Jahre an. Diese
341 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall, 341 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
342 bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus 342 bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
343 erfordert zwangslaeufig mehr Code, deshalb sind diese 343 erfordert zwangsläufig mehr Code, deshalb sind diese
344 Implementierungen tendenziell umfangreicher. 344 Implementierungen tendenziell umfangreicher.
345 345
346 346
347 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie 347 SLOC Zeilen Bytes Gehört zu Dateidatum Kategorie
348 ----------------------------------------------------------------- 348 -----------------------------------------------------------------
349 116 123 2966 System III 1980-04-11 (hist) 349 116 123 2966 System III 1980-04-11 (hist)
350 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist) 350 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist)
351 200 256 5715 4.3BSD-Reno 1990-06-25 (hist) 351 200 256 5715 4.3BSD-Reno 1990-06-25 (hist)
352 200 270 6545 NetBSD 1993-03-21 (hist) 352 200 270 6545 NetBSD 1993-03-21 (hist)
358 391 479 10961 FreeBSD 2012-11-24 (POSIX) 358 391 479 10961 FreeBSD 2012-11-24 (POSIX)
359 588 830 23167 GNU coreutils 2015-05-01 (pseudo) 359 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
360 360
361 361
362 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei 362 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
363 urspruenglichen Implementierungen, die sich nur minimal 363 ursprünglichen Implementierungen, die sich nur minimal
364 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit 364 unterscheiden, mit gut 100 SLOCs. (2) Die fünf BSD-Versionen mit
365 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und 365 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
366 die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die 366 die alte GNU-Version mit 340-390 SLOCs. Und schließlich (4) die
367 moderne GNU-Variante mit fast 600 SLOCs. 367 moderne GNU-Variante mit fast 600 SLOCs.
368 368
369 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit 369 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
370 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc 370 SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (`wc
371 -l') erstreckt sich ueber eine Spanne von Faktor 1.06 bei den 371 -l') erstreckt sich über eine Spanne von Faktor 1.06 bei den
372 aeltesten Vertretern bis zu Faktor 1.5 bei GNU. Den groessten 372 ältesten Vertretern bis zu Faktor 1.5 bei GNU. Den größten
373 Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und 373 Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und
374 die Groesse des Lizenzblocks am Dateianfang. 374 die Größe des Lizenzblocks am Dateianfang.
375 375
376 Betrachtet man die Abweichungen zwischen den logischen Codezeilen 376 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
377 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld 377 und der Dateigröße (`wc -c'), so pendelt das Teilnehmerfeld
378 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung 378 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
379 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit 379 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
380 fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren 380 fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren
381 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern. 381 Programmierstil, mit spezieller Einrückung und langen Bezeichnern.
382 Ob man die Heirloom-Implementierung als besonders kryptisch 382 Ob man die Heirloom-Implementierung
383 [ XXX
384 als besonders kryptisch
383 oder als besonders elegant bezeichnen will, das soll der 385 oder als besonders elegant bezeichnen will, das soll der
384 eigenen Einschaetzung des Lesers ueberlassen bleiben. Vor allem 386 eigenen Einschätzung des Lesers überlassen bleiben. Vor allem
385 der Vergleich mit einer GNU-Implementierung ist eindrucksvoll. 387 der Vergleich mit einer GNU-Implementierung
386 388 [ XXX
387 389 ist eindrucksvoll.
388 Die interne Struktur der Programmcodes (in C) ist meist aehnlich. 390
391
392 Die interne Struktur der Programmcodes (in C) ist meist ähnlich.
389 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente 393 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
390 verarbeitet, gibt es im Normalfall eine Funktion, die die 394 verarbeitet, gibt es im Normalfall eine Funktion, die die
391 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren 395 Feldauswahl in eine interne Datenstruktur überführt. Desweiteren
392 haben fast alle Implementierungen separate Funktionen fuer die 396 haben fast alle Implementierungen separate Funktionen für die
393 zwei oder drei Modi. Bei den POSIX-konformen Implementierungen 397 zwei oder drei Modi. Bei den POSIX-konformen Implementierungen
394 wird die `-b -n'-Kombination als weiterer Modus behandelt, und 398 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
395 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen 399 damit in einer eigenen Funktion umgesetzt. Nur bei der frühen
396 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) 400 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
397 wird ausser den Fehlerausgaben alles in der main-Funktion 401 wird außer den Fehlerausgaben alles in der main-Funktion
398 erledigt. 402 erledigt.
399 403
400 Cut-Implementierungen haben typischerweise zwei limitierende 404 Cut-Implementierungen haben typischerweise zwei limitierende
401 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale 405 Größen: Die Maximalanzahl unterstützter Felder und die maximale
402 Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt. 406 Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt.
403 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe 407 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
404 Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen 408 Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
405 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei 409 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
406 Heirloom kann sowohl die Felderanzahl als auch die maximale 410 Heirloom kann sowohl die Felderanzahl als auch die maximale
407 Zeilenlaenge beliebig gross werden; der Speicher dafuer wird 411 Zeilenlänge beliebig groß werden; der Speicher dafür wird
408 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer 412 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
409 Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die 413 Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die
410 begrenzte Felderanzahl scheint jedoch kein Praxisproblem 414 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
411 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus 415 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
412 gross genug sein sollte. 416 groß genug sein sollte.
413 417
414 418
415 Beschreibungen 419 Beschreibungen
416 420
417 Interessant ist zudem ein Vergleich der Kurzbeschreibungen von 421 Interessant ist zudem ein Vergleich der Kurzbeschreibungen von
446 450
447 POSIX cut out selected fields of each line of a file 451 POSIX cut out selected fields of each line of a file
448 452
449 453
450 Die mit ``(src)'' markierten Beschreibungen sind aus dem 454 Die mit ``(src)'' markierten Beschreibungen sind aus dem
451 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt 455 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält
452 die Beschreibung im Standard. Der ``Unix Reader'' ist ein 456 die Beschreibung im Standard. Der ``Unix Reader'' ist ein
453 rueckblickendes Textdokument von Doug McIlroy, das das 457 rückblickendes Textdokument von Doug McIlroy, das das
454 Auftreten der Tools in der Geschichte des Research Unix zum 458 Auftreten der Tools in der Geschichte des Research Unix zum
455 Thema hat. 459 Thema hat.
456 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf 460 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
457 Eigentlich sollte seine Beschreibung der in Version 8 Unix 461 Eigentlich sollte seine Beschreibung der in Version 8 Unix
458 entsprechen. Die Abweichung koennte ein Uebertragungsfehler 462 entsprechen. Die Abweichung könnte ein Übertragungsfehler
459 oder eine nachtraegliche Korrektur sein. Alle uebrigen 463 oder eine nachträgliche Korrektur sein. Alle übrigen
460 Beschreibungen entstammen den Manpages. 464 Beschreibungen entstammen den Manpages.
461 465
462 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen 466 Oft ist mit der Zeit die POSIX-Beschreibung übernommen
463 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD. 467 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
464 [ https://svnweb.freebsd.org/base?view=revision&revision=167101 468 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
465 469
466 Interessant ist, dass die GNU coreutils seit Anbeginn vom 470 Interessant ist, dass die GNU coreutils seit Anbeginn vom
467 Entfernen von Teilen der Eingabe sprechen, wohingegen die 471 Entfernen von Teilen der Eingabe sprechen, wohingegen die
468 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die 472 Kommandozeilenangabe klar ein Auswählen darstellt. Die
469 Worte ``cut out'' sind vielleicht auch zu missverstaendlich. 473 Worte ``cut out'' sind vielleicht auch zu missverständlich.
470 HP-UX hat sie deshalb praezisiert. 474 HP-UX hat sie deshalb präzisiert.
471 475
472 Beim Begriff, was selektiert wird, ist man sich ebenfalls 476 Beim Begriff, was selektiert wird, ist man sich ebenfalls
473 uneins. Die Einen reden von Feldern (POSIX), Andere von 477 uneins. Die Einen reden von Feldern (POSIX), Andere von
474 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten 478 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
475 (Research Unix). Ironischerweise leistet sich gerade Version 479 (Research Unix). Ironischerweise leistet sich gerade Version
476 8 Unix, das eigentlich um eine sehr treffende Weltsicht 480 8 Unix, das eigentlich um eine sehr treffende Weltsicht
477 bemueht ist, mit ``rearrange columns of data'' die 481 bemüht ist, mit ``rearrange columns of data'' die
478 unzutreffendste der Beschreibungen. 482 unzutreffendste der Beschreibungen.
479 483
480 484
481 Autoreninfo 485 Autoreninfo
482 486
483 Markus Schnalke interessiert sich fuer die Hintergruende 487 Markus Schnalke interessiert sich für die Hintergründe
484 von Unix und seinen Werkzeugen. Fuer die Erarbeitung dieses 488 von Unix und seinen Werkzeugen. Für die Erarbeitung dieses
485 Textes wurde er regelrecht zum Historiker. 489 Textes wurde er regelrecht zum Historiker.
486 490
487 491
488 Lizenz 492 Lizenz
489 493
490 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported 494 CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
491 veroeffentlicht werden) 495 veröffentlicht werden)