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