docs/cut

diff cut.txt @ 10:7e1214b556b9

Zwischenstand
author markus schnalke <meillo@marmaro.de>
date Mon, 11 May 2015 07:09:00 +0200
parents e67bd0d48bd6
children 04a8a33fc48a
line diff
     1.1 --- a/cut.txt	Tue May 05 19:21:00 2015 +0200
     1.2 +++ b/cut.txt	Mon May 11 07:09:00 2015 +0200
     1.3 @@ -36,11 +36,13 @@
     1.4  
     1.5  Mit cut lassen sich aber auch Strings kuerzen.
     1.6  
     1.7 -	$ echo "$long" | cut -c -20
     1.8 +	$ long=12345678901234567890
     1.9 +	$ echo "$long" | cut -c -10
    1.10 +	1234567890
    1.11  
    1.12 -Dieser Befehl gibt die ersten maximal 20 Zeichen von
    1.13 +Dieser Befehl gibt die ersten maximal 10 Zeichen von
    1.14  `$long' aus. (Alternativ kann man hierfuer auch `printf
    1.15 -"%.20s\n" "$long"' verwenden.)
    1.16 +"%.10s\n" "$long"' verwenden.)
    1.17  
    1.18  Geht es aber nicht um die Darstellung von Zeichen, sondern um
    1.19  ihre Speicherung, dann ist `-c' nicht unbedingt geeignet.
    1.20 @@ -62,14 +64,21 @@
    1.21  Textdateien mit begrenzter Zeilenlaenge erzeugen kann.
    1.22  [ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17
    1.23  
    1.24 -Neben dem Zeichen- bzw. Byte-Modus bietet cut noch den
    1.25 +Auch wenn der Bytemodus neu eingefuehrt wurde, so sollte er
    1.26 +sich doch nur so verhalten wie der alte Zeichenmodus normalerweise
    1.27 +implementiert war. Beim Zeichenmodus aber wurde durch POSIX.2
    1.28 +eine andere Implementierungsweise gefordert. Das Problem war
    1.29 +also nicht, den neuen Bytemodus zu implementieren, sondern
    1.30 +den Zeichenmodus neu zu implementieren.
    1.31 +
    1.32 +Neben dem Zeichen- und Byte-Modus bietet cut noch den
    1.33  Feld-Modus, den man mit `-f' einleitet. Mit ihm
    1.34  koennen Felder ausgewaehlt werden. Das Trennzeichen (per
    1.35  Default der Tab) kann mit `-d' geaendert werden.
    1.36  
    1.37  Der typische Anwendungsfall fuer cut im Feld-Modus ist die
    1.38  Auswahl von Information aus der passwd-Datei. So z.B. der
    1.39 -Benutername, seine ID und das Homeverzeichnis:
    1.40 +Benutzername, seine ID und das Homeverzeichnis:
    1.41  
    1.42  	$ cut -d: -f1,3,6 /etc/passwd
    1.43  	root:0:/root
    1.44 @@ -110,8 +119,7 @@
    1.45  parlance, it projects a relation.''
    1.46  [ XXX
    1.47  Cut fuehrt also die Datenbankoperation Projektion auf
    1.48 -Textdateien aus. Die Wikipedia erklaert das in
    1.49 -verstaendlicherer Sprache:
    1.50 +Textdateien aus. Die Wikipedia erklaert das folgendermassen:
    1.51  
    1.52  	Die Projektion entspricht der Projektionsabbildung aus der
    1.53  	Mengenlehre und kann auch Attributbeschränkung genannt
    1.54 @@ -137,7 +145,7 @@
    1.55  gefunden.
    1.56  XXX mail an TUHS
    1.57  
    1.58 -Aber werfen wir doch einen Blick auf die BSD-Linie: Dort ist mein
    1.59 +Nun ein Blick auf die BSD-Linie: Dort ist mein
    1.60  fruehester Fund ein cut.c mit dem Dateimodifikationsdatum
    1.61  1986-11-07
    1.62  [ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut
    1.63 @@ -157,9 +165,9 @@
    1.64  erwaehnt bereits die erwartete Konformitaet mit POSIX.2.
    1.65  XXX 2 oder 3 modi?
    1.66  Nun sollte man wissen, dass POSIX.2 erst im September
    1.67 -1992 veroeffentlicht wurde, also gut zwei Jahren *nachdem* die
    1.68 +1992 veroeffentlicht wurde, also gut zwei Jahren nachdem die
    1.69  Manpage und das Programm geschrieben wurden. Das Programm
    1.70 -wurde also anhand von Arbeitsversionen des Standards
    1.71 +wurde folglich anhand von Arbeitsversionen des Standards
    1.72  implementiert. Zweieinhalb Jahre Arbeit war immerhin schon in
    1.73  den Standardisierungsprozess geflossen; bis zur
    1.74  Fertigstellung sollte es aber noch weitere zwei Jahre dauern.
    1.75 @@ -167,8 +175,8 @@
    1.76  Das cut der GNU Coreutils enthaelt einen Copyrightvermerk von
    1.77  David M. Ihnat aus dem Jahr 1984.
    1.78  
    1.79 -Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut
    1.80 -aus Sicht des urspruenglichen Unix zu den juengeren Tools.
    1.81 +Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut,
    1.82 +aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
    1.83  Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
    1.84  so war Unix doch schon ueber zehn Jahre alt, als cut das
    1.85  erste Mal auftauchte. Insbesondere gehoerte cut auch noch nicht
    1.86 @@ -198,10 +206,10 @@
    1.87  Nun sind der Bytemodus und die damit verbundene
    1.88  Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit
    1.89  1992 standardisiert, wie steht es aber mit deren Umsetzung?
    1.90 -Welche Versionen implementieren denn den POSIX korrekt?
    1.91 +Welche Versionen implementieren POSIX korrekt?
    1.92  Die Situation ist dreiteilig: Es gibt traditionelle
    1.93  Implementierungen, die nur -c und -f kennen. Dann gibt es
    1.94 -Implementierungen die zwar -b kennen, es aber nur als Alias
    1.95 +Implementierungen die -b zwar kennen, es aber lediglich als Alias
    1.96  fuer -c handhaben. Diese Implementierungen funktionieren mit
    1.97  Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei
    1.98  Multi-Byte-Encodings (z.B. UTF-8) verhaelt sich ihr -c aber
    1.99 @@ -212,7 +220,7 @@
   1.100  Traditionelle Zwei-Modi-Implementierungen sind z.B. die von
   1.101  System III, System V und die aller BSDs bis in die 90er.
   1.102  
   1.103 -Pseude-Multibyte-Implementierungen bieten GNU und die
   1.104 +Pseudo-Multibyte-Implementierungen bieten GNU und die
   1.105  modernen NetBSDs und OpenBSDs. Wie sehr dort ein Schein von
   1.106  POSIX-Konformitaet gewahrt wird, ist unterschiedlich. Nicht
   1.107  immer findet man klare Aussagen wie diese:
   1.108 @@ -249,8 +257,8 @@
   1.109  Zeilenumbruch fuegt echo(1) hinzu.)
   1.110  
   1.111  Mit dem Programm iconv(1) kann man Text explizit in bestimmte
   1.112 -Kodierungen konvertieren. Hier Beispiele, wie das Ergebnis
   1.113 -bei Latin1 und wie es bei UTF-8 aussieht.
   1.114 +Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe
   1.115 +bei Latin1 und wie sie bei UTF-8 aussieht.
   1.116  
   1.117  	$ echo ä | iconv -t latin1 | od -c        
   1.118  	0000000 344  \n
   1.119 @@ -266,21 +274,21 @@
   1.120  Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System,
   1.121  dann sollte sich eine POSIX-konforme Implementierung so verhalten:
   1.122  
   1.123 -	$ echo aä | ./cut -c -2 | od -c
   1.124 -	0000000   a 303 244  \n
   1.125 -	0000004
   1.126 -
   1.127 -	$ echo aä | ./cut -b -2 | od -c
   1.128 -	0000000   a 303  \n
   1.129 +	$ echo ä | ./cut -c 1 | od -c
   1.130 +	0000000 303 244  \n
   1.131  	0000003
   1.132  
   1.133 -	$ echo aä | ./cut -b -2 -n | od -c
   1.134 -	0000000   a  \n
   1.135 +	$ echo ä | ./cut -b 1 | od -c
   1.136 +	0000000 303  \n
   1.137  	0000002
   1.138  
   1.139 -Bei einer Implementierung, die -b und -c gleich behandelt,
   1.140 -ist die Ausgabe in allen drei Faellen wie die mittlere: Es
   1.141 -werden die ersten beiden Bytes ausgegeben.
   1.142 +	$ echo ä | ./cut -b 1 -n | od -c
   1.143 +	0000000  \n
   1.144 +	0000001
   1.145 +
   1.146 +Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in
   1.147 +allen drei Faellen wie die mittlere: Es wird das erste Byte
   1.148 +ausgegeben.
   1.149  
   1.150  
   1.151  Implementierungen
   1.152 @@ -330,7 +338,7 @@
   1.153  und der Dateigroesse (`wc -c'), so pendelt das Teilnehmerfeld
   1.154  zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung
   1.155  weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit
   1.156 -fast 40 nach oben. Dies liegt bei GNU hauptsaechlich am
   1.157 +fast 40 nach oben. Dies liegt bei GNU hauptsaechlich an deren
   1.158  Programmierstil, mit spezieller Einrueckung und langen Bezeichnern.
   1.159  Ob man die Heirloom-Implementierung als besonders kryptisch
   1.160  oder als besonders elegant bezeichnen will, das soll der
   1.161 @@ -384,10 +392,9 @@
   1.162  NetBSD		select portions of each line of a file
   1.163  OpenBSD 4.6	select portions of each line of a file
   1.164  FreeBSD 1.0	select portions of each line of a file
   1.165 -FreeBSD 7.0	cut out selected portions of each line of a file
   1.166 +FreeBSD 10.0	cut out selected portions of each line of a file
   1.167  SunOS 4.1.3	remove selected fields from each line of a file
   1.168  SunOS 5.5.1	cut out selected fields of each line of a file
   1.169 -XXX FreeBSD 10
   1.170  
   1.171  Heirloom Tools	cut out selected fields of each line of a file
   1.172  Heirloom Tools (src)	cut out fields of lines of files
   1.173 @@ -423,10 +430,10 @@
   1.174  Interessant ist, dass die GNU coreutils seit Anbeginn vom
   1.175  Entfernen von Teilen der Eingabe sprechen, wohingegen die
   1.176  Kommandozeilenangabe klar ein Auswaehlen darstellt. Die
   1.177 -Worte ``cut out'' sind vielleicht auch etwas
   1.178 +Worte ``cut out'' sind vielleicht auch nur etwas zu
   1.179  missverstaendlich. HP-UX hat sie deshalb praezisiert.
   1.180  
   1.181 -Auch beim Begriff, was denn nun selektiert wird, ist man sich
   1.182 +Auch beim Begriff, was selektiert wird, ist man sich
   1.183  uneins. Die einen reden von Feldern (POSIX), andere von
   1.184  Abschnitten bzw. Teilen (BSD) und wieder andere von Spalten
   1.185  (Research Unix). Ironischerweise leistet sich gerade Version
   1.186 @@ -443,5 +450,6 @@
   1.187  
   1.188  
   1.189  Lizenz
   1.190 +
   1.191  CC0 (und kann damit auch unter CC BY-SA 4.0 Unported
   1.192  veroeffentlicht werden)