docs/cut

view cut.de.ms @ 39:7608a7416bc0

find changesets by author, revision, files, or words in the commit message
Some more minor rewording
author markus schnalke <meillo@marmaro.de>
date Thu, 05 Nov 2015 17:27:04 +0100
parents 3b4e53e04958
children
line source
1 .so macros
2 .lc_ctype de_DE.utf8
3
4 .TL
5 Cut out selected fields of each line of a file
6 .AU
7 markus schnalke <meillo@marmaro.de>
8 ..
9 .FS
10 2015-05.
11 Dieser Text steht unter CC0.
12 Er ist online verfügbar:
13 .I http://marmaro.de/docs/
14 .FE
15
16 .LP
17 Cut ist ein klassisches Programm im Unix-Werkzeugkasten.
18 In keinem ordentlichen Tutorial zur Shellprogrammierung fehlt
19 es, denn es ist ein schönes, praktisches und anschauliches
20 Helferlein. Hier soll ein wenig hinter seine Fassade geschaut
21 werden.
22 .SH
23 Funktionsweise
24 .LP
25 Ursprünglich hatte cut zwei Modi, die später um einen dritten
26 erweitert wurden. Cut schneidet entweder gewünschte Zeichen aus
27 den Zeilen der Eingabe oder gewünschte, durch Trennzeichen
28 definierte, Felder.
29 .PP
30 Der Zeichenmodus ist optimal geeignet um Festbreitenformate zu
31 zerteilen. Man kann damit beispielsweise bestimmte
32 Zugriffsrechte aus der Ausgabe von \f(CWls -l\fP ausschneiden, in
33 diesem Beispiel die Rechte des Besitzers:
34 .CS
35 $ ls -l foo
36 -rw-rw-r-- 1 meillo users 0 May 12 07:32 foo
37 .sp .3
38 $ ls -l foo | cut -c 2-4
39 rw-
40 .CE
41 .LP
42 Oder die Schreibrechte des Besitzers, der Gruppe und der
43 Welt:
44 .CS
45 $ ls -l foo | cut -c 3,6,9
46 ww-
47 .CE
48 .LP
49 Mit cut lassen sich aber auch Strings kürzen.
50 .CS
51 $ long=12345678901234567890
52 .sp .3
53 $ echo "$long" | cut -c -10
54 1234567890
55 .CE
56 .LP
57 Dieser Befehl gibt die ersten maximal 10 Zeichen von
58 \f(CW$long\fP aus. (Alternativ kann man hierfür \f(CWprintf
59 "%.10s\\n" "$long"\fP verwenden.)
60 .PP
61 Geht es aber nicht um die Darstellung von Zeichen, sondern um
62 ihre Speicherung, dann ist \f(CW-c\fP nur bedingt geeignet.
63 Früher, als US-ASCII noch die omnipräsente Zeichenkodierung
64 war, wurde jedes Zeichen mit genau einem
65 Byte gespeichert. Somit selektierte \f(CWcut -c\fP gleichermaßen
66 sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von
67 Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von
68 dieser Annahme lösen. In diesem Zug bekam cut mit
69 POSIX.2-1992 einen Bytemodus (Option \f(CW-b\fP). Will man
70 also nur die ersten maximal 500 Bytes vor dem
71 Newline-Zeichen stehen haben (und den Rest stillschweigend
72 ignorieren), dann macht man das mit:
73 .CS
74 $ cut -b -500
75 .CE
76 .LP
77 Den Rest kann man sich mit \f(CWcut -b 501-\fP einfangen. Diese
78 Funktion ist insbesondere für POSIX wichtig, da man damit
79 Textdateien mit begrenzter Zeilenlänge erzeugen kann
80 .[[ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 .
81 .PP
82 Wenn auch der Bytemodus neu eingeführt worden war, so sollte
83 er sich doch nur so verhalten wie der alte Zeichenmodus
84 normalerweise schon implementiert war. Beim Zeichenmodus wurde
85 dagegen eine neue Implementierungsweise gefordert. Das Problem
86 war folglich nicht, den neuen Bytemodus zu implementieren, sondern
87 den Zeichenmodus neu zu implementieren.
88 .PP
89 Neben dem Zeichen- und Bytemodus bietet cut noch den
90 Feldmodus, den man mit \f(CW-f\fP einleitet. Mit ihm
91 können Felder ausgewählt werden. Das Trennzeichen (per
92 Default der Tab) kann mit \f(CW-d\fP ge\%ändert werden. Es gilt in
93 gleicher Weise für die Eingabe und die Ausgabe.
94 .PP
95 Der typische Anwendungsfall für cut im Feldmodus ist die
96 Auswahl von Information aus der passwd-Datei. Hier z.B. der
97 Benutzername und seine ID:
98 .CS
99 $ cut -d: -f1,3 /etc/passwd
100 root:0
101 bin:1
102 daemon:2
103 mail:8
104 ...
105 .CE
106 .LP
107 (Die Argumente für die Optionen können bei cut übrigens
108 sowohl mit Whitespace abgetrennt als auch direkt angehängt folgen.)
109 .PP
110 Dieser Feldmodus ist für einfache tabellarische Dateien,
111 wie eben die passwd, gut geeignet. Er kommt aber schnell an
112 seine Grenzen. Gerade der häufige Fall, dass an Whitespace
113 in Felder geteilt werden soll, wird damit nicht abgedeckt.
114 Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann
115 demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt
116 werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander
117 stehende Trennzeichen führen zu einem leeren Feld. Dieses
118 Verhalten widerspricht den Erwartungen, die man an die
119 Verarbeitung einer Datei mit Whitespace-getrennten Feldern
120 hat. Manche Implementierungen von cut, z.B. die von FreeBSD,
121 haben deshalb Erweiterungen, die das gewünschte Verhalten
122 für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn
123 man portabel bleiben will, verwendet man awk in diesen
124 Fällen.
125 .PP
126 Awk bietet noch eine weitere Funktion, die cut missen
127 lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
128 cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
129 Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt
130 der Aufruf
131 von \f(CWcut -c 5-8,1,4-6\fP die Zeichen Nummer 1, 4, 5, 6, 7 und 8
132 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
133 der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
134 Teil der Ergebnismenge. Die Felder der Ergebnismenge sind
135 hierbei immer gleich geordnet wie in der Eingabe. Um die Worte
136 der Manpage von Version 8 Unix wiederzugeben: ``In data base
137 parlance, it projects a relation.''
138 .[[ http://man.cat-v.org/unix_8th/1/cut
139 Cut führt demnach die Datenbankoperation Projektion auf
140 Textdateien aus. Die Wikipedia
141 erklärt das folgendermaßen:
142 .QP
143 Die Projektion entspricht der Projektionsabbildung aus der
144 Mengenlehre und kann auch Attributbeschränkung genannt
145 werden. Sie extrahiert einzelne Attribute aus der
146 ursprünglichen Attributmenge und ist somit als eine Art
147 Selektion auf Spaltenebene zu verstehen, das heißt, die
148 Projektion blendet Spalten aus.
149 .[[ http://de.wikipedia.org/wiki/Projektion_(Informatik)#Projektion
150
151 .SH
152 Geschichtliches
153 .LP
154 Cut erblickte 1982 mit dem Release von UNIX System III das
155 Licht der öffentlichen Welt. Wenn man die Quellen von System
156 III durchforstet, findet man cut.c mit dem Zeitstempel 1980-04-11
157 .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd .
158 Das ist die älteste Implementierung des Programms, die ich
159 aufstöbern konnte. Allerdings spricht die SCCS-ID im
160 Quellcode von Version 1.5. Die Vorgeschichte liegt, der Vermutung
161 Doug McIlroys
162 .[[ http://minnie.tuhs.org/pipermail/tuhs/2015-May/004083.html
163 zufolge, in PWB/UNIX, dessen Entwicklungslinie die Grundlage für
164 System III war. In den von PWB 1.0 (1977) verfügbaren Quellen
165 .[[ http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/
166 ist cut noch nicht zu finden. Von PWB 2.0 scheinen keine
167 Quellen oder hilf\%reiche Dokumentation verfügbar zu sein.
168 PWB 3.0 wurde später aus Marketinggründen als System III
169 bezeichnet und ist folglich mit ihm identisch. Eine Nebenlinie zu
170 PWB war CB UNIX, das nur innerhalb
171 der Bell Labs genutzt wurde. Das Handbuch von CB UNIX Edition 2.1
172 vom November 1979 enthält die früheste Erwähnung von cut, die
173 meine Recherche zutage gefördert hat: eine Manpage für cut
174 .[[ ftp://sunsite.icm.edu.pl/pub/unix/UnixArchive/PDP-11/Distributions/other/CB_Unix/cbunix_man1_02.pdf .
175 .PP
176 Nun ein Blick auf die BSD-Linie: Dort ist der früheste
177 Fund ein cut.c mit dem Datei\%modifikationsdatum 1986-11-07
178 .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
179 als Teil der Spezialversion 4.3BSD-UWisc
180 .[[ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix ,
181 die im Januar 1987 veröffentlicht wurde.
182 Die Implementierung unterscheidet sich nur minimal von der
183 in System III.
184 Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf.
185 Das darauf folgende 4.3BSD-Reno (1990) lieferte aber wieder
186 ein cut mit aus. Dieses cut war ein von Adam S. Moskowitz und
187 Marciano Pitargue neu implementiertes cut, das 1989 in BSD
188 aufgenommen wurde
189 .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut .
190 Seine Manpage
191 .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1
192 erwähnt bereits die erwartete Konformität mit POSIX.2.
193 Nun muss man wissen, dass POSIX.2 erst im September
194 1992 veröffentlicht wurde, erst gut zwei Jahren nachdem die
195 Manpage und das Programm geschrieben worden waren. Das Programm
196 wurde folglich anhand von Arbeitsversionen des Standards
197 implementiert. Ein Blick in den Code bekräftigt diese Vermutung.
198 In der Funktion zum Parsen der Feldauswahlliste findet sich
199 dieser Kommentar:
200 .QP
201 This parser is less restrictive than the Draft 9 POSIX spec.
202 POSIX doesn't allow lists that aren't in increasing order or
203 overlapping lists.
204 .LP
205 Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits
206 ein:
207 .QP
208 The elements in list can be repeated, can overlap, and can
209 be specified in any order.
210 .LP
211 Zudem listet Draft 11.2 alle drei Modi, während in diesem
212 BSD cut nur die zwei alten implementiert sind. Es könnte also
213 sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war.
214 Ohne Zugang zu Draft 9 oder 10, war es leider nicht möglich,
215 diese Vermutung zu prüfen.
216 .PP
217 Die Versionsnummern und Änderungsdaten der älteren
218 BSD-Implementierungen kann man aus den SCCS-IDs, die vom
219 damaligen Versionskontrollsystem in den Code eingefügt wurden,
220 ablesen. So z.B. bei 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''.
221 .PP
222 Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:
223 .CS
224 Copyright (C) 1997-2015 Free Software Foundation, Inc.
225 Copyright (C) 1984 David M. Ihnat
226 .CE
227 .LP
228 Der Code hat also recht alte Ursprünge. Wie aus weiteren
229 Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David
230 MacKenzie und später von Jim Meyering überarbeitet. Letzterer
231 hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
232 Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im
233 Copyright-Vermerk auftauchen, ist unklar.
234 .PP
235 Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut,
236 aus Sicht des ursprünglichen Unix, zu den jüngeren Tools.
237 Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist,
238 so war Unix schon über zehn Jahre alt, als cut das
239 erste Mal auftauchte. Insbesondere gehörte cut noch nicht
240 zu Version 7 Unix, das die Ausgangsbasis aller modernen
241 Unix-Systeme darstellt. Die weit komplexeren Programme sed
242 und awk waren dort aber schon vertreten. Man muss sich also
243 fragen, warum cut überhaupt noch entwickelt wurde, wo es
244 schon zwei Programme gab, die die Funktion von cut abdecken
245 konnten. Ein Argument für cut war sicher seine Kompaktheit und
246 die damit verbundene Geschwindigkeit gegenüber dem damals
247 trägen awk. Diese schlanke Gestalt ist es auch, die der
248 Unix-Philosopie entspricht: Mache eine Aufgabe und die richtig!
249 Cut überzeugte. Es wurde in andere Unix Varianten übernommen,
250 stan\%dard\%isiert und ist heutzutage überall anzutreffen.
251 .PP
252 Die ursprüngliche Variante (ohne \f(CW-b\fP) wurde schon 1985 in
253 der System V Interface Definition, einer wichtigen formalen
254 Beschreibung von UNIX System V, spezifiziert und tauchte
255 anschließend in allen relevanten Standards auf. Mit POSIX.2
256 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form
257 (mit \f(CW-b\fP) standardisiert.
258
259 .pl -1
260 .SH
261 Multibyte-Unterstützung
262 .LP
263 Nun sind der Bytemodus und die damit verbundene
264 Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
265 1992 standardisiert, wie steht es aber mit deren Umsetzung?
266 Welche Versionen implementieren POSIX korrekt?
267 Die Situation ist dreiteilig: Es gibt historische
268 Implementierungen, die nur \f(CW-c\fP und \f(CW-f\fP kennen. Dann gibt es
269 Implementierungen die \f(CW-b\fP zwar kennen, es aber lediglich als Alias
270 für \f(CW-c\fP hand\%haben. Diese Implementierungen funktionieren mit
271 Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
272 Multibyte-Encodings (z.B. UTF-8) verhält sich ihr \f(CW-c\fP aber
273 wie \f(CW-b\fP (und \f(CW-n\fP wird ignoriert). Schließlich gibt es noch
274 Implementierungen, die \f(CW-b\fP und \f(CW-c\fP tatsächlich POSIX-konform
275 implementieren.
276 .PP
277 Historische Zwei-Modi-Implementierungen sind die von
278 System III, System V und die aller BSDs bis in die 90er.
279 .PP
280 Pseudo-Multibyte-Implementierungen bieten GNU und die
281 modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen,
282 ob dort ein Schein von POSIX-Konformität gewahrt wird.
283 Teilweise findet man erst nach genauerer Suche heraus, dass
284 \f(CW-c\fP und \f(CW-n\fP nicht wie erwartet funktionieren; teilweise machen es
285 sich die Systeme auch einfach, indem sie auf
286 Singlebyte-Zeichenkodierungen beharren, das aber dafür
287 klar darlegen:
288 .QP
289 Since we don't support multi-byte characters, the \f(CW-c\fP and \f(CW-b\fP
290 options are equivalent, and the \f(CW-n\fP option is meaningless.
291 .[[ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
292 .LP
293 Tatsächlich standardkonforme Implementierungen, die
294 Multibytes korrekt handhaben, bekommt man bei einem modernen
295 FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins
296 im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert
297 .[[ https://svnweb.freebsd.org/base?view=revision&revision=131194 .
298 Warum die beiden anderen großen BSDs diese Änderung nicht
299 übernommen haben, bleibt offen. Es scheint aber an der im
300 obigen Kommentar formulierten Grundausrichtung zu liegen.
301 .PP
302 Wie findet man nun als Nutzer heraus, ob beim cut des eigenen
303 Systems Multibytes korrekt unterstützt werden? Zuerst ist
304 entscheidend, ob das System selbst mit einem Multibyte-Encoding
305 arbeitet, denn tut es das nicht, dann entsprechen sich
306 Zeichen und Bytes und die Frage erübrigt sich. Man kann das
307 herausfinden indem man sich das Locale anschaut, aber einfacher
308 ist es, ein typisches Mehrbytezeichen, wie z.B. einen Umlaut,
309 auszugeben und zu schauen ob dieses in einem oder in mehreren
310 Bytes kodiert ist:
311 .CS
312 $ echo ä | od -c
313 0000000 303 244 \\n
314 0000003
315 .CE
316 .LP
317 In diesem Fall sind es zwei Bytes: oktal 303 und 244. (Den
318 Zeilenumbruch fügt echo hinzu.)
319 .PP
320 Mit dem Programm iconv kann man Text explizit in bestimmte
321 Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
322 bei Latin1 und wie sie bei UTF-8 aussieht:
323 .CS
324 $ echo ä | iconv -t latin1 | od -c
325 0000000 344 \\n
326 0000002
327 .sp .3
328 $ echo ä | iconv -t utf8 | od -c
329 0000000 303 244 \\n
330 0000003
331 .CE
332 .LP
333 Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung)
334 wird recht sicher einer dieser beiden Ausgaben entsprechen.
335 .PP
336 Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
337 dann sollte sich eine POSIX-konforme Implementierung folgendermaßen
338 verhalten:
339 .CS
340 $ echo ä | cut -c 1 | od -c
341 0000000 303 244 \\n
342 0000003
343 .sp .3
344 $ echo ä | cut -b 1 | od -c
345 0000000 303 \\n
346 0000002
347 .sp .3
348 $ echo ä | cut -b 1 -n | od -c
349 0000000 \\n
350 0000001
351 .CE
352 .LP
353 Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
354 allen drei Fällen wie die mittlere: Es wird das erste Byte
355 ausgegeben.
356
357 .pl +1
358 .SH
359 Implementierungen
360 .LP
361 Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an
362 Implementierungen.
363 .PP
364 Für einen ersten Eindruck ist der Umfang des Quellcodes
365 hilfreich. Typischerweise steigt dieser über die Jahre an. Diese
366 Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall,
367 bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus
368 erfordert zwangsläufig mehr Code, deshalb sind diese
369 Implementierungen tendenziell umfangreicher.
370 .TS
371 center;
372 r r r l l l.
373 SLOC Zeilen Bytes Gehört zu Dateidatum Kategorie
374 _
375 116 123 2966 System III 1980-04-11 historisch
376 118 125 3038 4.3BSD-UWisc 1986-11-07 historisch
377 200 256 5715 4.3BSD-Reno 1990-06-25 historisch
378 200 270 6545 NetBSD 1993-03-21 historisch
379 218 290 6892 OpenBSD 2008-06-27 pseudo-POSIX
380 224 296 6920 FreeBSD 1994-05-27 historisch
381 232 306 7500 NetBSD 2014-02-03 pseudo-POSIX
382 340 405 7423 Heirloom 2012-05-20 POSIX
383 382 586 14175 GNU coreutils 1992-11-08 pseudo-POSIX
384 391 479 10961 FreeBSD 2012-11-24 POSIX
385 588 830 23167 GNU coreutils 2015-05-01 pseudo-POSIX
386 .TE
387 .LP
388 Das Kandidatenfeld teilt sich grob in vier Gruppen: (1) Die zwei
389 ursprünglichen Implementierungen, die sich nur minimal
390 unterscheiden, mit gut 100 SLOCs. (2) Die fünf BSD-Versionen mit
391 gut 200 SLOCs. (3) Die zwei POSIX-konformen Programme und
392 die alte GNU-Version mit 340\(en390 SLOCs. Und schließlich (4) die
393 moderne GNU-Variante mit fast 600 SLOCs.
394 .PP
395 Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit
396 SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (\f(CWwc
397 -l\fP) erstreckt sich über eine Spanne von Faktor 1,06 bei den
398 ältesten Vertretern bis zu Faktor 1,5 bei GNU. Den größten
399 Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und
400 die Größe des Lizenzblocks am Dateianfang.
401 .PP
402 Betrachtet man die Abweichungen zwischen den logischen Codezeilen
403 und der Dateigröße (\f(CWwc -c\fP), so pendelt das Teilnehmerfeld
404 zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
405 weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
406 fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren
407 Programmierstil, mit spezieller Einrückung und langen Bezeichnern.
408 Ob man die Heirloom-Implementierung
409 .[[ http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/cut/cut.c?revision=1.6&view=markup
410 als besonders kryptisch
411 oder als besonders elegant bezeichnen will, das soll der
412 eigenen Einschätzung des Lesers überlassen bleiben. Vor allem
413 der Vergleich mit einer GNU-Implementierung
414 .[[ http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cut.c;hb=e981643
415 ist eindrucksvoll.
416 .PP
417 Die interne Struktur der Programmcodes (in C) ist meist ähnlich.
418 Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente
419 verarbeitet, gibt es im Normalfall eine Funktion, die die
420 Feldauswahl in eine interne Datenstruktur überführt. Desweiteren
421 haben fast alle Implementierungen separate Funktionen für jeden
422 ihrer Modi. Bei den POSIX-konformen Implementierungen
423 wird die \f(CW-b -n\fP-Kombination als weiterer Modus behandelt, und
424 damit in einer eigenen Funktion umgesetzt. Nur bei der frühen
425 System III-Implementierung (und seiner 4.3BSD-UWisc-Variante)
426 wird außer den Fehlerausgaben alles in der main-Funktion
427 erledigt.
428 .PP
429 Cut-Implementierungen haben typischerweise zwei limitierende
430 Größen: Die Maximalanzahl unterstützter Felder und die maximale
431 Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt.
432 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe
433 Grenzen (\f(CW_BSD_LINE_MAX\fP bzw. \f(CW_POSIX2_LINE_MAX\fP). Bei modernen
434 FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei
435 Heirloom kann sowohl die Felderanzahl als auch die maximale
436 Zeilenlänge beliebig groß werden; der Speicher dafür wird
437 dynamisch alloziiert. OpenBSD ist ein Hybrid aus fixer
438 Maximalzahl an Feldern und beliebiger Zeilenlänge. Die
439 begrenzte Felderanzahl scheint jedoch kein Praxisproblem
440 darzustellen, da \f(CW_POSIX2_LINE_MAX\fP mit mindestens 2048 durchaus
441 groß genug sein sollte.
442
443 .SH
444 Beschreibungen
445 .LP
446 Interessant ist zudem ein Vergleich der Kurzbeschreibungen von
447 cut, wie sie sich in der Titelzeile der Manpages oder manchmal
448 am Anfang der Quellcodedatei finden. Die folgende Liste
449 ist grob zeitlich geordnet und nach Abstammung gruppiert:
450 .TS
451 center;
452 l l.
453 CB UNIX cut out selected fields of each line of a file
454 System III cut out selected fields of each line of a file
455 System III \(dg cut and paste columns of a table (projection of a relation)
456 System V cut out selected fields of each line of a file
457 HP-UX cut out (extract) selected fields of each line of a file
458 .sp .3
459 4.3BSD-UWisc \(dg cut and paste columns of a table (projection of a relation)
460 4.3BSD-Reno select portions of each line of a file
461 NetBSD select portions of each line of a file
462 OpenBSD 4.6 select portions of each line of a file
463 FreeBSD 1.0 select portions of each line of a file
464 FreeBSD 10.0 cut out selected portions of each line of a file
465 SunOS 4.1.3 remove selected fields from each line of a file
466 SunOS 5.5.1 cut out selected fields of each line of a file
467 .sp .3
468 Heirloom Tools cut out selected fields of each line of a file
469 Heirloom Tools \(dg cut out fields of lines of files
470 .sp .3
471 GNU coreutils remove sections from each line of files
472 .sp .3
473 Minix select out columns of a file
474 .sp .3
475 Version 8 Unix rearrange columns of data
476 ``Unix Reader'' rearrange columns of text
477 .sp .3
478 POSIX cut out selected fields of each line of a file
479 .TE
480 .LP
481 Die mit `\(dg' markierten Beschreibungen sind aus dem
482 jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält
483 die Beschreibung im Standard. Der ``Unix Reader'' ist ein
484 rückblickendes Textdokument von Doug McIlroy, das das
485 Auftreten der Tools in der Geschichte des Research Unix zum
486 Thema hat
487 .[[ http://doc.cat-v.org/unix/unix-reader/contents.pdf .
488 Eigentlich sollte seine Beschreibung der in Version 8 Unix
489 entsprechen. Die Abweichung könnte ein Übertragungsfehler
490 oder eine nachträgliche Korrektur sein. Alle übrigen
491 Beschreibungen entstammen den Manpages.
492 .PP
493 Oft ist mit der Zeit die POSIX-Beschreibung übernommen
494 oder an sie angeglichen worden, wie beispielsweise bei FreeBSD
495 .[[ https://svnweb.freebsd.org/base?view=revision&revision=167101 .
496 .PP
497 Interessant ist, dass die GNU coreutils seit Anbeginn vom
498 Entfernen von Teilen der Eingabe sprechen, wohingegen die
499 Kommandozeilenangabe klar ein Auswählen darstellt. Die
500 Worte ``cut out'' sind vielleicht auch zu missverständlich.
501 HP-UX hat sie deshalb präzisiert.
502 .PP
503 Beim Begriff, was selektiert wird, ist man sich ebenfalls
504 uneins. Die Einen reden von Feldern (POSIX), Andere von
505 Abschnitten bzw. Teilen (BSD) und wieder Andere von Spalten
506 (Research Unix).
507 .PP
508 Die scheinbar unzutreffende Beschreibung
509 bei Version 8 Unix (``rearrange columns of data'') ist
510 dadurch zu erklären, dass die Manpage sowohl cut als auch
511 paste abdeckt. In ihrer Kombination können tatsächlich
512 Spalten umgeordnet werden.
513
514 .SH
515 Referenzen
516 .LP
517 .nf
518 ._r
519