1.1 --- a/cut.txt	Mon May 11 17:14:00 2015 +0200
     1.2 +++ b/cut.txt	Mon May 11 17:47:00 2015 +0200
     1.3 @@ -109,7 +109,15 @@
     1.4  Awk bietet noch eine weitere Funktion, die cut missen
     1.5  laesst: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei
     1.6  cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein
     1.7 -Feld kann selbst mehrfach angegeben werden. So gibt der Aufruf
     1.8 +Feld kann selbst mehrfach angegeben werden.
     1.9 +
    1.10 +XXX 4.3BSD-Reno + *BSDs
    1.11 +         * This parser is less restrictive than the Draft 9 POSIX spec.
    1.12 +         * POSIX doesn't allow lists that aren't in increasing order or
    1.13 +         * overlapping lists.  We also handle "-3-5" although there's no
    1.14 +         * real reason too.
    1.15 +
    1.16 +So gibt der Aufruf
    1.17  von `cut -c 5-8,1,4-6' die Zeichen Nummer 1, 4, 5, 6, 7 und 8
    1.18  in genau dieser Reihenfolge aus. Die Auswahl entspricht damit
    1.19  der Mengenlehre in der Mathematik: Jedes angegebene Feld wird
    1.20 @@ -172,10 +180,35 @@
    1.21  den Standardisierungsprozess geflossen; bis zur
    1.22  Fertigstellung sollte es aber noch weitere zwei Jahre dauern.
    1.23  
    1.24 -Das cut der GNU Coreutils enthaelt einen Copyrightvermerk von
    1.25 -David M. Ihnat aus dem Jahr 1984.
    1.26 +Schaut man sich die SCCS-IDs (die vom damaligen
    1.27 +Versionskontrollsystem eingefuegt wurden) in den BSD-Quellen an,
    1.28 +dann findet man dort Versionsnummern, die die Entstehung
    1.29 +dokumentieren:
    1.30  
    1.31 -Trotz all dieser Jahreszahlen aus den 80er Jahren gehoert cut,
    1.32 +	4.3BSD-UWisc	"@(#)cut.c      1.3";
    1.33 +	4.3BSD-Reno	"@(#)cut.c      5.3 (Berkeley) 6/24/90";
    1.34 +	NetBSD		"@(#)cut.c      5.4 (Berkeley) 10/30/90";
    1.35 +	FreeBSD		"@(#)cut.c      8.1 (Berkeley) 6/6/93";
    1.36 +
    1.37 +Die neueren BSD-Versionen enthalten zwar weiterhin eine SCCS-ID, diese
    1.38 +ist aber bei Version "8.3 (Berkeley) 5/4/95" stehen geblieben. Danach
    1.39 +wurde scheinbar von SCCS auf ein anderes
    1.40 +Versionskontrollsystem gewechselt.
    1.41 +XXX
    1.42 +
    1.43 +Das cut der GNU Coreutils enthaelt folgenden Copyrightvermerk:
    1.44 +
    1.45 +	Copyright (C) 1997-2015 Free Software Foundation, Inc.
    1.46 +	Copyright (C) 1984 David M. Ihnat
    1.47 +
    1.48 +Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren
    1.49 +Kommentaren zu entnehmen ist, wurde der Code zuerst von David
    1.50 +MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
    1.51 +hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
    1.52 +Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk
    1.53 +auftauchen, ist unklar.
    1.54 +
    1.55 +Trotz der vielen Jahreszahlen aus den 80er Jahren gehoert cut,
    1.56  aus Sicht des urspruenglichen Unix, zu den juengeren Tools.
    1.57  Wenn cut auch ein Jahrzehnt aelter als Linux, der Kernel, ist,
    1.58  so war Unix doch schon ueber zehn Jahre alt, als cut das
    1.59 @@ -357,53 +390,16 @@
    1.60  wird nichts aus der main-Funktion ausgelagert, ausser den
    1.61  Fehlerausgaben.
    1.62  
    1.63 -Bei System III ist die Anzahl der moeglichen Felder und damit auch
    1.64 -die Zeilenlaenge auf 512 begrenzt.
    1.65 +Bei System III ist die Anzahl der moeglichen Felder und ebenso
    1.66 +die Zeilenlaenge auf 512 begrenzt. 4.3BSD-Reno und die BSDs
    1.67 +der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX
    1.68 +bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei
    1.69 +allen GNU-Implementierungen und bei Heirloom kann sowohl
    1.70 +die Felderanzahl als auch die maximale Zeilenlaenge beliebig
    1.71 +gross werden; der Speicher dafür wird dynamisch alloziiert.
    1.72 +OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber
    1.73 +beliebiger Zeilenlaenge (fgetln). XXX
    1.74  
    1.75 -Bei 4.3BSD-Reno liegt die Grenze bei _BSD_LINE_MAX
    1.76 -
    1.77 -NetBSD 1993 _POSIX2_LINE_MAX
    1.78 -
    1.79 -NetBSD 2012 dyn alloc
    1.80 -
    1.81 -
    1.82 -4.3BSD-Reno
    1.83 -         * set a byte in the positions array to indicate if a field or
    1.84 -         * column is to be selected; use +1, it's 1-based, not 0-based.
    1.85 -         * This parser is less restrictive than the Draft 9 POSIX spec.
    1.86 -         * POSIX doesn't allow lists that aren't in increasing order or
    1.87 -         * overlapping lists.  We also handle "-3-5" although there's no
    1.88 -         * real reason too.
    1.89 -
    1.90 -
    1.91 -
    1.92 -Schaut man sich die SCCS-IDs (die vom damaligen
    1.93 -Versionskontrollsystem eingefuegt wurden) in den BSD-Quellen an,
    1.94 -dann findet man dort Versionsnummern, die die Entwicklung
    1.95 -dokumentieren:
    1.96 -
    1.97 -	4.3bsd-uwisc	"@(#)cut.c      1.3";
    1.98 -	4.3bsd-reno	"@(#)cut.c      5.3 (Berkeley) 6/24/90";
    1.99 -	netbsd		"@(#)cut.c      5.4 (Berkeley) 10/30/90";
   1.100 -	freebsd		"@(#)cut.c      8.1 (Berkeley) 6/6/93";
   1.101 -
   1.102 -Die neueren BSD-Versionen enthalten zwar weiterhin eine SCCS-ID, diese
   1.103 -ist aber bei Version "8.3 (Berkeley) 5/4/95" stehen geblieben. Danach
   1.104 -wurde scheinbar von SCCS auf ein anderes
   1.105 -Versionskontrollsystem gewechselt.
   1.106 -XXX
   1.107 -
   1.108 -Bei GNU befindet sich folgender Copyright-Vermerk im Code:
   1.109 -
   1.110 -	Copyright (C) 1997-2015 Free Software Foundation, Inc.
   1.111 -	Copyright (C) 1984 David M. Ihnat
   1.112 -
   1.113 -Der Code hat also ziemlich alte Urspruenge. Wie aus weiteren
   1.114 -Kommentaren zu entnehmen ist, wurde der Code zuerst von David
   1.115 -MacKenzie und spaeter von Jim Meyering ueberarbeitet. Letzterer
   1.116 -hat den Code 1992 auch ins Versionkontrollsystem eingestellt.
   1.117 -Weshalb die Jahre zwischen 1992 und 1997 nicht im Copyright-Vermerk
   1.118 -auftauchen, ist unklar.
   1.119  
   1.120  
   1.121  Beschreibungen