Mercurial > docs > cut

comparison cut.txt @ 17:08f539a5445d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Ueberarbeitung der Formulierungen, hauptsaechlich
author markus schnalke <meillo@marmaro.de>
date Wed, 13 May 2015 07:18:16 +0200
parents 4d8196c836d8
children b1e7b45fb3c8
comparison
equal deleted inserted replaced
16:4d8196c836d8 17:08f539a5445d
45 `$long' aus. (Alternativ kann man hierfuer `printf 45 `$long' aus. (Alternativ kann man hierfuer `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 als Zeichensatz und -kodierung 50 Frueher, als US-ASCII noch die omnipraesente Zeichenkodierung
51 noch omnipraesent 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' gleichermassen
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 loesen. 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
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 so 64 Funktion ist insbesondere fuer POSIX wichtig, da man so
65 Textdateien mit begrenzter Zeilenlaenge erzeugen kann. 65 Textdateien mit begrenzter Zeilenlaenge 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 Auch wenn der Bytemodus neu eingefuehrt wurde, so sollte er 68 Wenn auch der Bytemodus neu eingefuehrt worden war, so sollte
69 sich doch nur so verhalten wie der alte Zeichenmodus normalerweise 69 er sich doch nur so verhalten wie der alte Zeichenmodus
70 implementiert war. Beim Zeichenmodus aber wurde durch POSIX.2 70 normalerweise schon implementiert war. Beim Zeichenmodus aber
71 eine andere Implementierungsweise gefordert. Das Problem war 71 wurde eine neue Implementierungsweise gefordert. Das Problem
72 also nicht, den neuen Bytemodus zu implementieren, sondern 72 war also 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 Byte-Modus bietet cut noch den 75 Neben dem Zeichen- und Bytemodus bietet cut noch den
76 Feld-Modus, 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 koennen Felder ausgewaehlt werden. Das Trennzeichen (per
78 Default der Tab) kann mit `-d' geaendert werden. 78 Default der Tab) kann mit `-d' geaendert werden.
79 79
80 Der typische Anwendungsfall fuer cut im Feld-Modus ist die 80 Der typische Anwendungsfall fuer cut im Feldmodus ist die
81 Auswahl von Information aus der passwd-Datei. So z.B. der 81 Auswahl von Information aus der passwd-Datei. So z.B. der
82 Benutzername, seine ID und das Homeverzeichnis: 82 Benutzername und seine ID:
83 83
84 $ cut -d: -f1,3,6 /etc/passwd 84 $ cut -d: -f1,3 /etc/passwd
85 root:0:/root 85 root:0
86 bin:1:/bin 86 bin:1
87 daemon:2:/sbin 87 daemon:2
88 mail:8:/var/spool/mail 88 mail:8
89 ... 89 ...
90 90
91 (Die Argumente fuer die Optionen koennen bei cut uebrigens 91 (Die Argumente fuer die Optionen koennen bei cut uebrigens
92 mit Whitespace abgetrennt oder direkt angehaengt folgen.) 92 mit Whitespace abgetrennt oder direkt angehaengt folgen.)
93 93
94 Dieser Feld-Modus ist fuer einfache tabellarische Dateien, 94 Dieser Feldmodus ist fuer einfache tabellarische Dateien,
95 wie eben die passwd, gut geeignet. Er kommt aber schnell an 95 wie eben die passwd, gut geeignet. Er kommt aber schnell an
96 seine Grenzen. Gerade der haeufige Fall, dass an Whitespace 96 seine Grenzen. Gerade der haeufige Fall, dass an Whitespace
97 in Felder geteilt werden soll, wird damit nicht abgedeckt. 97 in Felder geteilt werden soll, wird damit nicht abgedeckt.
98 Der Delimiter kann nur genau ein Zeichen sein. Es kann also 98 Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
99 nicht sowohl an Leerzeichen als auch an Tabs getrennt werden. 99 also nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
100 Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander 100 werden. Auch unterteilt cut an jedem Trennzeichen. Zwei aneinander
101 stehende Trennzeichen fuehren zu einem leeren Feld. Dieses 101 stehende Trennzeichen fuehren zu einem leeren Feld. Dieses
102 Verhalten widerspricht den Erwartungen, die man an die 102 Verhalten widerspricht den Erwartungen, die man an die
103 Verarbeitung einer Datei mit Whitespace-getrennten Feldern 103 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
104 hat. Manche Implementierungen von cut, z.B. die von FreeBSD, 104 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
105 haben aber Erweiterungen, die das gewuenschte Verhalten fuer 105 haben deshalb Erweiterungen, die das gewuenschte Verhalten
106 Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn 106 fuer Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
107 man portabel bleiben will, verwendet man awk in diesen 107 man portabel bleiben will, verwendet man awk in diesen
108 Faellen. 108 Faellen.
109 109
110 Awk bietet noch eine weitere Funktion, die cut missen 110 Awk bietet noch eine weitere Funktion, die cut missen
111 laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei 111 laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
138 Licht der oeffentlichen Welt. Wenn man die Quellen von System 138 Licht der oeffentlichen Welt. Wenn man die Quellen von System
139 III durchforstet, findet man die Quellcodedatei cut.c mit dem 139 III durchforstet, findet man die Quellcodedatei cut.c mit dem
140 Zeitstempel 1980-04-11. 140 Zeitstempel 1980-04-11.
141 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd 141 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
142 Das ist die aelteste Manifestation des Programms, die ich 142 Das ist die aelteste Manifestation des Programms, die ich
143 aufstoebern konnte. Allerdings spricht die sccsid im 143 aufstoebern konnte. Allerdings spricht die SCCS-ID im
144 Quellcode von Version 1.5. Es muss also noch eine 144 Quellcode von Version 1.5. Es muss also noch eine
145 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang 145 Vorgeschichte geben. Zu dieser habe ich leider keinen Zugang
146 gefunden. 146 gefunden.
147 XXX mail an TUHS 147 XXX mail an TUHS
148 148
149 Nun ein Blick auf die BSD-Linie: Dort ist mein 149 Nun ein Blick auf die BSD-Linie: Dort ist mein fruehester
150 fruehester Fund ein cut.c mit dem Dateimodifikationsdatum 150 Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07
151 1986-11-07
152 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut 151 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
153 als Teil der Spezialversion 4.3BSD-UWisc, 152 als Teil der Spezialversion 4.3BSD-UWisc,
154 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix 153 [ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix
155 die im Januar 1987 veroeffentlicht wurde. 154 die im Januar 1987 veroeffentlicht wurde.
156 Die Implementierung unterscheidet sich nur minimal von der 155 Die Implementierung unterscheidet sich nur minimal von der
157 in System III. 156 in System III.
158 Im bekannteren 4.3BSD-Tahoe (1988) taucht cut nicht auf. 157 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
159 Das darauf folgende 4.3BSD-Reno (1990) liefert aber wieder 158 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
160 ein cut mit aus. Dieses cut ist ein von Adam S. Moskowitz und 159 ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
161 Marciano Pitargue neu implementiertes cut, das 1989 in BSD 160 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
162 aufgenommen wurde. 161 aufgenommen wurde.
163 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut 162 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut
164 Seine Manpage 163 Seine Manpage
165 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1 164 [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
166 erwaehnt bereits die erwartete Konformitaet mit POSIX.2. 165 erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
167 XXX 2 oder 3 modi? Draft 9: 2 modi? Draft 11.2 hat 3 modi! 166 Nun muss man wissen, dass POSIX.2 erst im September
168 Nun sollte man wissen, dass POSIX.2 erst im September
169 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die 167 1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
170 Manpage und das Programm geschrieben wurden. Das Programm 168 Manpage und das Programm geschrieben worden waren. Das Programm
171 wurde folglich anhand von Arbeitsversionen des Standards 169 wurde folglich anhand von Arbeitsversionen des Standards
172 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung. 170 implementiert. Ein Blick in den Code bekraeftigt diese Vermutung.
173 In der Funktion zum parsen der Feldauswahlliste findet sich 171 In der Funktion zum parsen der Feldauswahlliste findet sich
174 dieser Kommentar: 172 dieser Kommentar:
175 173
181 ein: 179 ein:
182 180
183 The elements in list can be repeated, can overlap, and can 181 The elements in list can be repeated, can overlap, and can
184 be specified in any order. 182 be specified in any order.
185 183
186 Die Versionsnummern und Aenderungsdatums der aelteren 184 Auch listet Draft 11.2 alle drei Modi, waehrend in diesem
187 BSD-Implementierungen kann man aus den SCCS-IDs (die vom 185 BSD cut nur die zwei alten implementiert sind. Es koennte also
188 damaligen Versionskontrollsystem in den Code eingefuegt wurden) 186 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
187 Da ich keinen Zugang zu Draft 9 oder 10 finden konnte, war es mir
188 leider nicht moeglich, diese Vermutung zu pruefen. XXX
189
190 Die Versionsnummern und Aenderungsdaten der aelteren
191 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
192 damaligen Versionskontrollsystem in den Code eingefuegt wurden,
189 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. 193 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
190 194
191 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk: 195 Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
192 196
193 Copyright (C) 1997-2015 Free Software Foundation, Inc. 197 Copyright (C) 1997-2015 Free Software Foundation, Inc.
194 Copyright (C) 1984 David M. Ihnat 198 Copyright (C) 1984 David M. Ihnat
195 199
196 Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren 200 Der Code hat also recht alte Urspruenge. Wie aus weiteren
197 Kommentaren zu entnehmen ist, wurde der Code zuerst von David 201 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
198 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer 202 MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
199 hat den Code 1992 auch ins Versionkontrollsystem eingestellt. 203 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
200 Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk 204 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
201 auftauchen, ist unklar. 205 Copyright-Vermerk auftauchen, ist unklar.
202 206
203 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut, 207 Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
204 aus Sicht des urspruenglichen Unix, zu den juengeren Tools. 208 aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
205 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist, 209 Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
206 so war Unix doch schon ueber zehn Jahre alt, als cut das 210 so war Unix doch schon ueber zehn Jahre alt, als cut das
210 und awk waren dort schon vertreten. Man muss sich also 214 und awk waren dort schon vertreten. Man muss sich also
211 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es 215 fragen, warum cut ueberhaupt noch entwickelt wurde, wo es
212 schon zwei Programme gab, die die Funktion von cut abdecken 216 schon zwei Programme gab, die die Funktion von cut abdecken
213 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und 217 konnten. Ein Argument fuer cut war sicher seine Kompaktheit und
214 die damit verbundene Geschwindigkeit gegenueber dem damals 218 die damit verbundene Geschwindigkeit gegenueber dem damals
215 traegen awk. Diese schlanke Gestalt ist es auch, die der Unix 219 traegen awk. Diese schlanke Gestalt ist es auch, die der
216 Philosopie entspricht: Mache eine Aufgabe und die richtig! 220 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
217 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen, 221 Cut ueberzeugte. Es wurde in andere Unix Varianten uebernommen,
218 standardisiert und ist heutzutage ueberall anzutreffen. 222 standardisiert und ist heutzutage ueberall anzutreffen.
219 223
220 Die urspruengliche Variante (ohne -b) wurde schon 1985 in 224 Die urspruengliche Variante (ohne -b) wurde schon 1985 in
221 der System V Interface Definition, einer wichtigen formalen 225 der System V Interface Definition, einer wichtigen formalen
230 234
231 Nun sind der Bytemodus und die damit verbundene 235 Nun sind der Bytemodus und die damit verbundene
232 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit 236 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
233 1992 standardisiert, wie steht es aber mit deren Umsetzung? 237 1992 standardisiert, wie steht es aber mit deren Umsetzung?
234 Welche Versionen implementieren POSIX korrekt? 238 Welche Versionen implementieren POSIX korrekt?
235 Die Situation ist dreiteilig: Es gibt traditionelle 239 Die Situation ist dreiteilig: Es gibt historische
236 Implementierungen, die nur -c und -f kennen. Dann gibt es 240 Implementierungen, die nur -c und -f kennen. Dann gibt es
237 Implementierungen die -b zwar kennen, es aber lediglich als Alias 241 Implementierungen die -b zwar kennen, es aber lediglich als Alias
238 fuer -c handhaben. Diese Implementierungen funktionieren mit 242 fuer -c handhaben. Diese Implementierungen funktionieren mit
239 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei 243 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
240 Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber 244 Multibyte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
241 wie -b (und -n wird ignoriert). Schliesslich gibt es noch 245 wie -b (und -n wird ignoriert). Schliesslich gibt es noch
242 Implementierungen, die -b und -c tatsaechlich POSIX-konform 246 Implementierungen, die -b und -c tatsaechlich POSIX-konform
243 implementieren. 247 implementieren.
244 248
245 Traditionelle Zwei-Modi-Implementierungen sind z.B. die von 249 Historische Zwei-Modi-Implementierungen sind z.B. die von
246 System III, System V und die aller BSDs bis in die 90er. 250 System III, System V und die aller BSDs bis in die 90er.
247 251
248 Pseudo-Multibyte-Implementierungen bieten GNU und die 252 Pseudo-Multibyte-Implementierungen bieten GNU und die
249 modernen NetBSDs und OpenBSDs. Man darf sich durchaus fragen, 253 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
250 ob dort ein Schein von POSIX-Konformitaet gewahrt wird. 254 ob dort ein Schein von POSIX-Konformitaet gewahrt wird.
251 Teilweise findet man erst nach genauerer Suche heraus, dass 255 Teilweise findet man erst nach genauerer Suche heraus, dass
252 -c und -n nicht wie erwartet funktionieren; teilweise machen es 256 -c und -n nicht wie erwartet funktionieren; teilweise machen es
253 sich die System auch einfach, indem sie auf 257 sich die Systeme auch einfach, indem sie auf
254 Singlebyte-Zeichenkodierungen beharren, das aber dafuer klar 258 Singlebyte-Zeichenkodierungen beharren, das aber dafuer meist
255 darlegen: 259 klar darlegen:
256 260
257 Since we don't support multi-byte characters, the -c and -b 261 Since we don't support multi-byte characters, the -c and -b
258 options are equivalent, and the -n option is meaningless. 262 options are equivalent, and the -n option is meaningless.
259 263
260 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup 264 [ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
266 [ https://svnweb.freebsd.org/base?view=revision&revision=131194 270 [ https://svnweb.freebsd.org/base?view=revision&revision=131194
267 Warum die beiden anderen grossen BSDs diese Aenderung nicht 271 Warum die beiden anderen grossen BSDs diese Aenderung nicht
268 uebernommen haben, bleibt offen. Es scheint aber an der im 272 uebernommen haben, bleibt offen. Es scheint aber an der im
269 obigen Kommentar formulierten Grundausrichtung zu liegen. 273 obigen Kommentar formulierten Grundausrichtung zu liegen.
270 274
271 Wie findet man als Nutzer heraus, ob beim cut(1) des eigenen 275 Wie findet man nun als Nutzer heraus, ob beim cut(1) des eigenen
272 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist 276 Systems Multibytes korrekt unterstuetzt werden? Zuerst ist
273 entscheidend, ob das System selbst mit einem Multibyte-Encoding 277 entscheidend, ob das System selbst mit einem Multibyte-Encoding
274 arbeitet, denn tut es das nicht, dann entsprechen sich naemlich 278 arbeitet, denn tut es das nicht, dann entsprechen sich
275 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das 279 Zeichen und Bytes und die Frage eruebrigt sich. Man kann das
276 herausfinden indem man sich das Locale anschaut, aber einfacher 280 herausfinden indem man sich das Locale anschaut, aber einfacher
277 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut, 281 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
278 auszugeben und zu schauen ob dieses in einem oder in mehreren 282 auszugeben und zu schauen ob dieses in einem oder in mehreren
279 Bytes kodiert ist: 283 Bytes kodiert ist:
299 303
300 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung) 304 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
301 wird recht sicher einer dieser beiden Ausgaben entsprechen. 305 wird recht sicher einer dieser beiden Ausgaben entsprechen.
302 306
303 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System, 307 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
304 dann sollte sich eine POSIX-konforme Implementierung so verhalten: 308 dann sollte sich eine POSIX-konforme Implementierung folgendermassen
309 verhalten:
305 310
306 $ echo ä | ./cut -c 1 | od -c 311 $ echo ä | ./cut -c 1 | od -c
307 0000000 303 244 \n 312 0000000 303 244 \n
308 0000003 313 0000003
309 314
326 Implementierungen. 331 Implementierungen.
327 332
328 Fuer einen ersten Eindruck ist der Umfang des Quellcodes 333 Fuer einen ersten Eindruck ist der Umfang des Quellcodes
329 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese 334 hilfreich. Typischerweise steigt dieser ueber die Jahre an. Diese
330 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall, 335 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
331 bestaetigt werden. Die Unterstuetzung des Byte-Modus (-b) 336 bestaetigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
332 erfordert zwangslaeufig mehr Code, deshalb sind die 337 erfordert zwangslaeufig mehr Code, deshalb sind diese
333 POSIX-konformen Implementierungen tendenziell umfangreicher. 338 Implementierungen tendenziell umfangreicher.
334 339
335 340
336 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie 341 SLOC Zeilen Bytes Gehoert zu Dateidatum Kategorie
337 ----------------------------------------------------------------- 342 -----------------------------------------------------------------
338 116 123 2966 System III 1980-04-11 (trad) 343 116 123 2966 System III 1980-04-11 (hist)
339 118 125 3038 4.3BSD-UWisc 1986-11-07 (trad) 344 118 125 3038 4.3BSD-UWisc 1986-11-07 (hist)
340 200 256 5715 4.3BSD-Reno 1990-06-25 (trad) 345 200 256 5715 4.3BSD-Reno 1990-06-25 (hist)
341 200 270 6545 NetBSD 1993-03-21 (trad) 346 200 270 6545 NetBSD 1993-03-21 (hist)
342 218 290 6892 OpenBSD 2008-06-27 (pseudo) 347 218 290 6892 OpenBSD 2008-06-27 (pseudo)
343 224 296 6920 FreeBSD 1994-05-27 (trad) 348 224 296 6920 FreeBSD 1994-05-27 (hist)
344 232 306 7500 NetBSD 2014-02-03 (pseudo) 349 232 306 7500 NetBSD 2014-02-03 (pseudo)
345 340 405 7423 Heirloom 2012-05-20 (POSIX) 350 340 405 7423 Heirloom 2012-05-20 (POSIX)
346 382 586 14175 GNU coreutils 1992-11-08 (pseudo) 351 382 586 14175 GNU coreutils 1992-11-08 (pseudo)
347 391 479 10961 FreeBSD 2012-11-24 (POSIX) 352 391 479 10961 FreeBSD 2012-11-24 (POSIX)
348 588 830 23167 GNU coreutils 2015-05-01 (pseudo) 353 588 830 23167 GNU coreutils 2015-05-01 (pseudo)
350 355
351 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei 356 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
352 urspruenglichen Implementierungen, die sich nur minimal 357 urspruenglichen Implementierungen, die sich nur minimal
353 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit 358 unterscheiden, mit gut 100 SLOCs. (2) Die fuenf BSD-Versionen mit
354 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und 359 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
355 die alte GNU-Version mit 340-390 SLOCs. Und (4) die moderne 360 die alte GNU-Version mit 340-390 SLOCs. Und schliesslich (4) die
356 GNU-Variante mit fast 600 SLOCs. 361 moderne GNU-Variante mit fast 600 SLOCs.
357 362
358 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit 363 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
359 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc 364 SLOCcount) und der Anzahl von Zeilenumbruechen in der Datei (`wc
360 -l') erstreckt sich ueber einen Faktor von 1.06 bei den aeltesten 365 -l') erstreckt sich ueber einen Faktor von 1.06 bei den aeltesten
361 Vertretern bis zu Faktor 1.5 bei GNU. Der groesste 366 Vertretern bis zu Faktor 1.5 bei GNU. Der groesste
364 369
365 Betrachtet man die Abweichungen zwischen den logischen Codezeilen 370 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
366 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld 371 und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
367 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung 372 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
368 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit 373 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
369 fast 40 nach oben. Dies liegt bei GNU hauptsaechlich an deren 374 fast 40 nach oben. Bei GNU liegt dies hauptsaechlich an deren
370 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern. 375 Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
371 Ob man die Heirloom-Implementierung als besonders kryptisch 376 Ob man die Heirloom-Implementierung als besonders kryptisch
372 oder als besonders elegant bezeichnen will, das soll der 377 oder als besonders elegant bezeichnen will, das soll der
373 eigenen Einschaetzung des Lesers ueberlassen bleiben. 378 eigenen Einschaetzung des Lesers ueberlassen bleiben.
374 379
375 380
376 Die interne Struktur des C-Codes ist meist aehnlich. Neben der 381 Die interne Struktur der Programmcodes (in C) ist meist aehnlich.
377 obligatorischen main-Funktion, die die Kommandozeilenargumente 382 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
378 verarbeitet, gibt es im Normalfall eine Funktion, die die 383 verarbeitet, gibt es im Normalfall eine Funktion, die die
379 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren 384 Feldauswahl in eine interne Datenstruktur ueberfuehrt. Desweiteren
380 haben fast alle Implementierungen separate Funktionen fuer die 385 haben fast alle Implementierungen separate Funktionen fuer die
381 zwei bzw. drei Modi. Bei den POSIX-konformen Implementierungen 386 zwei bzw. drei Modi. Bei den POSIX-konformen Implementierungen
382 wird die `-b -n'-Kombination als weiterer Modus behandelt, und 387 wird die `-b -n'-Kombination als weiterer Modus behandelt, und
383 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen 388 damit in einer eigenen Funktion umgesetzt. Nur bei der fruehen
384 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) 389 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
385 wird ausser den Fehlerausgaben nichts aus der main-Funktion 390 wird ausser den Fehlerausgaben alles in der main-Funktion
386 ausgelagert. 391 erledigt.
387 392
388 Cut-Implementierungen haben typischerweise zwei limitierende 393 Cut-Implementierungen haben typischerweise zwei limitierende
389 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale 394 Groessen: Die Maximalanzahl unterstuetzter Felder und die maximale
390 Zeilenlaenge. Bei System III ist die Anzahl der moeglichen Felder 395 Zeilenlaenge. Bei System III sind beide Groessen auf 512 begrenzt.
391 und ebenso die Zeilenlaenge auf 512 begrenzt. 4.3BSD-Reno und die 396 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
392 BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX 397 Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen
393 bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei 398 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
394 allen GNU-Implementierungen und bei Heirloom kann sowohl 399 Heirloom kann sowohl die Felderanzahl als auch die maximale
395 die Felderanzahl als auch die maximale Zeilenlaenge beliebig 400 Zeilenlaenge beliebig gross werden; der Speicher dafür wird
396 gross werden; der Speicher dafür wird dynamisch alloziiert. 401 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
397 OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber 402 Maximalzahl an Feldern, aber beliebiger Zeilenlaenge. Die
398 beliebiger Zeilenlaenge. Die begrenzte Felderanzahl scheint 403 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
399 jedoch kein praktisches Problem darzustellen, da _POSIX2_LINE_MAX 404 darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus
400 mit mindestens 2048 durchaus genug Platz bieten sollte. 405 gross genug sein sollte.
401 406
402 407
403 Beschreibungen 408 Beschreibungen
404 409
405 Interessant ist auch ein Vergleich der Kurzbeschreibungen von 410 Interessant ist auch ein Vergleich der Kurzbeschreibungen von
406 cut, wie sie sich in der Titelzeile von Manpages oder manchmal 411 cut, wie sie sich in der Titelzeile der Manpages oder manchmal
407 auch am Anfang der Quellcodedatei finden. Die folgende Liste 412 auch am Anfang der Quellcodedatei finden. Die folgende Liste
408 ist grob zeitlich geordnet und nach Abstammung gruppiert: 413 ist grob zeitlich geordnet und nach Abstammung gruppiert:
409 414
410 415
411 System III cut out selected fields of each line of a file 416 System III cut out selected fields of each line of a file
434 439
435 POSIX cut out selected fields of each line of a file 440 POSIX cut out selected fields of each line of a file
436 441
437 442
438 Die mit ``(src)'' markierten Beschreibungen sind aus dem 443 Die mit ``(src)'' markierten Beschreibungen sind aus dem
439 jeweiligen Quellcode entnommen. 444 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthaelt
440 Der POSIX-Eintrag enthaelt die Beschreibung des Standards. 445 die Beschreibung des Standards. Der ``Unix Reader'' ist ein
441 Der ``Unix Reader'' ist ein rueckblickendes Textdokument von 446 rueckblickendes Textdokument von Doug McIlroy, das das
442 Doug McIlroy, das das Auftreten von Tools in der Geschichte 447 Auftreten von Tools in der Geschichte des Research Unix zum
443 des Research Unix zum Thema hat. 448 Thema hat.
444 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf 449 [ http://doc.cat-v.org/unix/unix-reader/contents.pdf
445 Eigentlich sollte seine 450 Eigentlich sollte seine Beschreibung der in Version 8 Unix
446 Beschreibung der in Version 8 Unix entsprechen. Die 451 entsprechen. Die Abweichung koennte sowohl ein
447 Abweichung koennte sowohl ein Uebertragungsfehler als auch 452 Uebertragungsfehler als auch eine nachtraegliche Korrektur
448 eine nachtraegliche Korrektur sein. 453 sein. Alle uebrigen Beschreibungen entstammen den Manpages.
449 Alle uebrigen Beschreibungen entstammen den Manpages.
450 454
451 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen 455 Oft ist mit der Zeit die POSIX-Beschreibung uebernommen
452 oder zumindest an sie angeglichen worden, wie beispielsweise 456 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD.
453 bei FreeBSD.
454 [ https://svnweb.freebsd.org/base?view=revision&revision=167101 457 [ https://svnweb.freebsd.org/base?view=revision&revision=167101
455 458
456 Interessant ist, dass die GNU coreutils seit Anbeginn vom 459 Interessant ist, dass die GNU coreutils seit Anbeginn vom
457 Entfernen von Teilen der Eingabe sprechen, wohingegen die 460 Entfernen von Teilen der Eingabe sprechen, wohingegen die
458 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die 461 Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
459 Worte ``cut out'' sind vielleicht auch nur etwas zu 462 Worte ``cut out'' sind vielleicht auch etwas zu
460 missverstaendlich. HP-UX hat sie deshalb praezisiert. 463 missverstaendlich. HP-UX hat sie deshalb praezisiert.
461 464
462 Auch beim Begriff, was selektiert wird, ist man sich 465 Auch beim Begriff, was selektiert wird, ist man sich
463 uneins. Die einen reden von Feldern (POSIX), andere von 466 uneins. Die Einen reden von Feldern (POSIX), Andere von
464 Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten 467 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
465 (Research Unix). Ironischerweise leistet sich gerade Version 468 (Research Unix). Ironischerweise leistet sich gerade Version
466 8 Unix, das eigentlich um eine sehr treffende Weltsicht 469 8 Unix, das eigentlich um eine sehr treffende Weltsicht
467 bemueht ist, mit ``rearrange columns of data'' die 470 bemueht ist, mit ``rearrange columns of data'' die
468 unzutreffendste der Beschreibungen. 471 unzutreffendste der Beschreibungen.
469 472