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