meillo@27: .so macros meillo@27: .lc_ctype en_US.utf8 meillo@27: .pl -4v meillo@27: meillo@27: .TL meillo@27: Cut out selected fields of each line of a file meillo@27: .AU meillo@27: markus schnalke meillo@27: .. meillo@27: .FS meillo@27: 2015-05. meillo@27: This text is in the public domain (CC0). meillo@27: It is available online: meillo@27: .I http://marmaro.de/docs/ meillo@27: .FE meillo@27: meillo@27: .LP meillo@27: Cut is a classic program in the Unix toolchest. meillo@27: It is present in most tutorials on shell programming, because it meillo@27: is such a nice and useful tool which good explanationary value. meillo@27: This text shall take a look behind its surface. meillo@27: .SH meillo@27: Usage meillo@27: .LP meillo@27: Initially, cut had two operation modes, which were amended by a meillo@27: third one, later. Cut may cut specified characters out of the meillo@27: input lines or it may cut out specified fields, which are defined meillo@27: by a delimiting character. meillo@27: .PP meillo@27: The character mode is well suited to slice fixed-width input meillo@27: formats into parts. One might, for instance, extract the access meillo@27: rights from the output of \f(CWls -l\fP, here the rights of the meillo@27: file's owner: meillo@27: .CS meillo@27: $ ls -l foo meillo@27: -rw-rw-r-- 1 meillo users 0 May 12 07:32 foo meillo@27: .sp .3 meillo@27: $ ls -l foo | cut -c 2-4 meillo@27: rw- meillo@27: .CE meillo@27: .LP meillo@27: Or the write permission for the owner, the group and the meillo@27: world: meillo@27: .CS meillo@27: $ ls -l foo | cut -c 3,6,9 meillo@27: ww- meillo@27: .CE meillo@27: .LP meillo@27: Cut can also be used to shorten strings: meillo@27: .CS meillo@27: $ long=12345678901234567890 meillo@27: .sp .3 meillo@27: $ echo "$long" | cut -c -10 meillo@27: 1234567890 meillo@27: .CE meillo@27: .LP meillo@27: This command outputs no more than the first 10 characters of meillo@27: \f(CW$long\fP. (Alternatively, on could use \f(CWprintf meillo@27: "%.10s\\n" "$long"\fP for this job.) meillo@27: .PP meillo@27: However, if it's not about displaying characters but about their meillo@27: storing, then \f(CW-c\fP is only partly suited. In former times, meillo@27: when US-ASCII had been the omnipresent character encoding, each meillo@27: character was stored with exactly one byte. Therefore, \f(CWcut meillo@27: -c\fP selected both, output characters and bytes, equally. With meillo@27: the uprise of multi-byte encodings (like UTF-8), this assumption meillo@27: became obsolete. Consequently, a byte mode (option \f(CW-b\fP) meillo@27: was added to cut, with POSIX.2-1992. To select the first up to meillo@27: 500 bytes of each line (and ignore the rest), one can use: meillo@27: .CS meillo@27: $ cut -b -500 meillo@27: .CE meillo@27: .LP meillo@27: The remainder can be caught with \f(CWcut -b 501-\fP. This meillo@27: possibility is important for POSIX, because it allows to create meillo@27: text files with limited line length meillo@27: .[[ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 . meillo@27: .PP meillo@27: Although the byte mode was newly introduced, it was meant to meillo@27: behave exactly as the old character mode. The character mode, meillo@27: however, had to be implemented differently. In consequence, meillo@27: the problem wasn't to support the byte mode, but to support the meillo@27: new character mode correctly. meillo@27: .PP meillo@27: Besides the character and byte modes, cut has the field mode, meillo@27: which is activated by \f(CW-f\fP. It selects fields from the meillo@27: input. The delimiting character (by default, the tab) may be meillo@27: changed using \f(CW-d\fP. It applies to the input as well as to meillo@27: the output. meillo@27: .PP meillo@27: The typical example for the use of cut's field mode is the meillo@27: selection of information from the passwd file. Here, for meillo@27: instance, the username and its uid: meillo@27: .CS meillo@27: $ cut -d: -f1,3 /etc/passwd meillo@27: root:0 meillo@27: bin:1 meillo@27: daemon:2 meillo@27: mail:8 meillo@27: ... meillo@27: .CE meillo@27: .LP meillo@27: (The values to the command line switches may be appended directly meillo@27: to them or separated by whitespace.) meillo@27: .PP meillo@27: The field mode is suited for simple tabulary data, like the meillo@27: passwd file. Beyond that, it soon reaches its limits. Especially, meillo@27: the typical case of whitespace-separated fields is covered poorly meillo@27: by it. Cut's delimiter is exactly one character, meillo@27: therefore one may not split at both, space and tab characters. meillo@27: Furthermore, multiple adjacent delimiter characters lead to meillo@27: empty fields. This is not the expected behavior for meillo@27: the processing of whitespace-separated fields. Some meillo@27: implementations, e.g. the one of FreeBSD, have extensions that meillo@27: handle this case in the expected way. Apart from that, i.e. meillo@27: if one likes to stay portable, awk comes to rescue. meillo@27: .PP meillo@27: Awk provides another function that cut misses: Changing the order meillo@27: of the fields in the output. For cut, the order of the field meillo@27: selection specification is irrelevant; it doesn't even matter if meillo@27: fields are given multiple times. Thus, the invocation meillo@27: \f(CWcut -c 5-8,1,4-6\fP outputs the characters number meillo@27: 1, 4, 5, 6, 7 and 8 in exactly this order. The meillo@27: selection is like in the mathematical set theory: Each meillo@27: specified field is part of the solution set. The fields in the meillo@27: solution set are always in the same order as in the input. To meillo@27: speak with the words of the man page in Version 8 Unix: meillo@27: ``In data base parlance, it projects a relation.'' meillo@27: .[[ http://man.cat-v.org/unix_8th/1/cut meillo@27: This means, cut applies the database operation \fIprojection\fP meillo@27: to the text input. Wikipedia explains it in the following way: meillo@27: ``In practical terms, it can be roughly thought of as picking a meillo@27: sub-set of all available columns.'' meillo@27: .[[ https://en.wikipedia.org/wiki/Projection_(relational_algebra) meillo@27: meillo@27: .SH meillo@27: Historical Background meillo@27: .LP meillo@27: Cut came to public life in 1982 with the release of UNIX System meillo@27: III. Browsing through the sources of System III, one finds cut.c meillo@27: with the timestamp 1980-04-11 meillo@27: .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd . meillo@27: This is the oldest implementation of the program, I was able to meillo@27: discover. However, the SCCS-ID in the source code speaks of meillo@27: version 1.5. According to Doug McIlroy meillo@27: .[[ http://minnie.tuhs.org/pipermail/tuhs/2015-May/004083.html , meillo@27: the earlier history likely lays in PWB/UNIX, which was the meillo@27: basis for System III. In the available sources of PWB 1.0 (1977) meillo@27: .[[ http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/ , meillo@27: no cut is present. Of PWB 2.0, no sources or useful documentation meillo@27: seem to be available. PWB 3.0 was later renamed to System III meillo@27: for marketing purposes, hence it is identical to it. A side line meillo@27: of PWB was CB UNIX, which was only used in the Bell Labs meillo@27: internally. The manual of CB UNIX Edition 2.1 of November 1979 meillo@27: contains the earliest mentioning of cut, that my research brought meillo@27: to light: A man page for it meillo@27: .[[ ftp://sunsite.icm.edu.pl/pub/unix/UnixArchive/PDP-11/Distributions/other/CB_Unix/cbunix_man1_02.pdf . meillo@27: .PP meillo@27: Now a look on BSD: There, my earliest discovery is a cut.c with meillo@27: the file modification date of 1986-11-07 meillo@27: .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut meillo@27: as part of the special version 4.3BSD-UWisc meillo@27: .[[ http://gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix , meillo@27: which was released in January 1987. meillo@27: This implementation is mostly identical to the one in System meillo@27: III. The better known 4.3BSD-Tahoe (1988) does not contain cut. meillo@27: The following 4.3BSD-Reno (1990) does include cut. It is a freshly meillo@27: written one by Adam S. Moskowitz and Marciano Pitargue, which was meillo@27: included in BSD in 1989 meillo@27: .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut . meillo@27: Its man page meillo@27: .[[ http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1 meillo@27: already mentions the expected compliance to POSIX.2. meillo@27: One should note that POSIX.2 was first published in meillo@27: September 1992, about two years after the man page and the meillo@27: program were written. Hence, the program must have been meillo@27: implemented based on a draft version of the standard. A look into meillo@27: the code confirms the assumption. The function to parse the field meillo@27: selection includes the following comment: meillo@27: .QP meillo@27: This parser is less restrictive than the Draft 9 POSIX spec. meillo@27: POSIX doesn't allow lists that aren't in increasing order or meillo@27: overlapping lists. meillo@27: .LP meillo@27: Draft 11.2 of POSIX (1991-09) requires this flexibility already: meillo@27: .QP meillo@27: The elements in list can be repeated, can overlap, and can meillo@27: be specified in any order. meillo@27: .LP meillo@27: The same draft additionally includes all three operation modes, meillo@27: whereas this early BSD cut only implemented the original two. meillo@27: Draft 9 might not have included the byte mode. Without access to meillo@27: Draft 9 or 10, it wasn't possible to verify this guess. meillo@27: .PP meillo@27: The version numbers and change dates of the older BSD meillo@27: implementations are manifested in the SCCS-IDs, which the meillo@27: version control system of that time inserted. For instance meillo@27: in 4.3BSD-Reno: ``5.3 (Berkeley) 6/24/90''. meillo@27: .PP meillo@27: The cut implementation of the GNU coreutils contains the meillo@27: following copyright notice: meillo@27: .CS meillo@27: Copyright (C) 1997-2015 Free Software Foundation, Inc. meillo@27: Copyright (C) 1984 David M. Ihnat meillo@27: .CE meillo@27: .LP meillo@27: The code does have pretty old origins. Further comments show that meillo@27: the source code was reworked by David MacKenzie first and later meillo@27: by Jim Meyering, who put it into the version control system in meillo@27: 1992. It is unclear, why the years until 1997, at least from meillo@27: 1992 on, don't show up in the copyright notice. meillo@27: .PP meillo@27: Despite all those year numbers from the 80s, cut is a rather meillo@27: young tool, at least in relation to the early Unix. Despite meillo@27: being a decade older than Linux, the kernel, Unix had been meillo@27: present for over ten years until cut appeared for the first meillo@27: time. Most notably, cut wasn't part of Version 7 Unix, which meillo@27: became the basis for all modern Unix systems. The more complex meillo@27: tools sed and awk had been part of it already. Hence, the meillo@27: question comes to mind, why cut was written at all, as there meillo@27: existed two programs that were able to cover the use cases of meillo@27: cut. On reason for cut surely was its compactness and the meillo@27: resulting speed, in comparison to the then bulky awk. This lean meillo@27: shape goes well with the Unix philosopy: Do one job and do it meillo@27: well! Cut convinced. It found it's way to other Unix variants, meillo@27: it became standardized and today it is present everywhere. meillo@27: .PP meillo@27: The original variant (without \f(CW-b\fP) was described by the meillo@27: System V Interface Defintion, an important formal description meillo@27: of UNIX System V, already in 1985. In the following years, it meillo@27: appeared in all relevant standards. POSIX.2 in 1992 specified meillo@27: cut for the first time in its modern form (with \f(CW-b\fP). meillo@27: meillo@27: .SH meillo@27: Multi-byte support meillo@27: .LP meillo@27: The byte mode and thus the multi-byte support of meillo@27: the POSIX character mode are standardized since 1992. But meillo@27: how about their presence in the available implementations? meillo@27: Which versions do implement POSIX correctly? meillo@27: .PP meillo@27: The situation is divided in three parts: There are historic meillo@27: implementations, which have only \f(CW-c\fP and \f(CW-f\fP. meillo@27: Then there are implementations, which have \f(CW-b\fP but meillo@27: treat it as an alias for \f(CW-c\fP only. These meillo@27: implementations work correctly for single-byte encodings meillo@27: (e.g. US-ASCII, Latin1) but for multi-byte encodings (e.g. meillo@27: UTF-8) their \f(CW-c\fP behaves like \f(CW-b\fP (and meillo@27: \f(CW-n\fP is ignored). Finally, there are implementations meillo@27: that implement \f(CW-b\fP and \f(CW-c\fP POSIX-compliant. meillo@27: .PP meillo@27: Historic two-mode implementations are the ones of meillo@27: System III, System V and the BSD ones until the mid-90s. meillo@27: .PP meillo@27: Pseudo multi-byte implementations are provided by GNU and meillo@27: modern NetBSD and OpenBSD. The level of POSIX compliance meillo@27: that is presented there is often higher than the level of meillo@27: compliance that is actually provided. Sometimes it takes a meillo@27: close look to discover that \f(CW-c\fP and \f(CW-n\fP don't meillo@27: behave as expected. Some of the implementations take the meillo@27: easy way by simply being ignorant to any multi-byte meillo@27: encodings, at least they tell that clearly: meillo@27: .QP meillo@27: Since we don't support multi-byte characters, the \f(CW-c\fP and \f(CW-b\fP meillo@27: options are equivalent, and the \f(CW-n\fP option is meaningless. meillo@27: .[[ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup meillo@27: .LP meillo@27: Standard-adhering implementations, ones that treat meillo@27: multi-byte characters correctly, are the one of the modern meillo@27: FreeBSD and the one in the Heirloom toolchest. Tim Robbins meillo@27: reimplemented the character mode of FreeBSD cut, meillo@27: conforming to POSIX, in summer 2004 meillo@27: .[[ https://svnweb.freebsd.org/base?view=revision&revision=131194 . meillo@27: The question, why the other BSD systems have not meillo@27: integrated this change, is an open one. Maybe the answer an be meillo@27: found in the above quoted statement. meillo@27: .PP meillo@27: How does a user find out if the cut on the own system handles meillo@27: multi-byte characters correclty? First, one needs to check if meillo@27: the system itself uses multi-byte characters, because otherwise meillo@27: characters and bytes are equivalent and the question meillo@27: is irrelevant. One can check this by looking at the locale meillo@27: settings, but it is easier to print a typical multi-byte meillo@27: character, for instance an Umlaut or the Euro currency meillo@27: symbol, and check if one or more bytes are output: meillo@27: .CS meillo@27: $ echo ä | od -c meillo@27: 0000000 303 244 \\n meillo@27: 0000003 meillo@27: .CE meillo@27: .LP meillo@27: In this case it were two bytes: octal 303 and 244. (The meillo@27: Newline character is added by echo.) meillo@27: .PP meillo@27: The program iconv converts text to specific encodings. This meillo@27: is the output for Latin1 and UTF-8, for comparison: meillo@27: .CS meillo@27: $ echo ä | iconv -t latin1 | od -c meillo@27: 0000000 344 \\n meillo@27: 0000002 meillo@27: .sp .3 meillo@27: $ echo ä | iconv -t utf8 | od -c meillo@27: 0000000 303 244 \\n meillo@27: 0000003 meillo@27: .CE meillo@27: .LP meillo@27: The output (without the iconv conversion) on many European meillo@27: systems equals one of these two. meillo@27: .PP meillo@27: Now the test of the cut implementation. On a UTF-8 system, a meillo@27: POSIX compliant implementation behaves as such: meillo@27: .CS meillo@27: $ echo ä | cut -c 1 | od -c meillo@27: 0000000 303 244 \\n meillo@27: 0000003 meillo@27: .sp .3 meillo@27: $ echo ä | cut -b 1 | od -c meillo@27: 0000000 303 \\n meillo@27: 0000002 meillo@27: .sp .3 meillo@27: $ echo ä | cut -b 1 -n | od -c meillo@27: 0000000 \\n meillo@27: 0000001 meillo@27: .CE meillo@27: .LP meillo@27: A pseudo POSIX implementation, in contrast, behaves like the meillo@27: middle one, for all three invocations: Only the first byte is meillo@27: output. meillo@27: meillo@27: .SH meillo@27: Implementations meillo@27: .LP meillo@27: Let's take a look at the sources of a selection of meillo@27: implementations. meillo@27: .PP meillo@27: A comparison of the amount of source code is good to get a first meillo@27: impression. Typically, it grows through time. This can be seen meillo@27: here, in general but not in all cases. A POSIX-compliant meillo@27: implementation of the character mode requires more code, thus meillo@27: these implementations are rather the larger ones. meillo@27: .TS meillo@27: center; meillo@27: r r r l l l. meillo@27: SLOC Lines Bytes Belongs to File tyime Category meillo@27: _ meillo@27: 116 123 2966 System III 1980-04-11 historic meillo@27: 118 125 3038 4.3BSD-UWisc 1986-11-07 historic meillo@27: 200 256 5715 4.3BSD-Reno 1990-06-25 historic meillo@27: 200 270 6545 NetBSD 1993-03-21 historic meillo@27: 218 290 6892 OpenBSD 2008-06-27 pseudo-POSIX meillo@27: 224 296 6920 FreeBSD 1994-05-27 historic meillo@27: 232 306 7500 NetBSD 2014-02-03 pseudo-POSIX meillo@27: 340 405 7423 Heirloom 2012-05-20 POSIX meillo@27: 382 586 14175 GNU coreutils 1992-11-08 pseudo-POSIX meillo@27: 391 479 10961 FreeBSD 2012-11-24 POSIX meillo@27: 588 830 23167 GNU coreutils 2015-05-01 pseudo-POSIX meillo@27: .TE meillo@27: .LP meillo@27: Roughly four groups can be seen: (1) The two original meillo@27: implementaions, which are mostly identical, with about 100 meillo@27: SLOC. (2) The five BSD versions, with about 200 SLOC. (3) The meillo@27: two POSIX-compliant versions and the old GNU one, with a SLOC meillo@27: count in the 300s. And finally (4) the modern GNU cut with meillo@27: almost 600 SLOC. meillo@27: .PP meillo@27: The variation between the number of logical code meillo@27: lines (SLOC, meassured with SLOCcount) and the number of meillo@27: Newlines in the file (\f(CWwc -l\fP) spans between factor meillo@27: 1.06 for the oldest versions and factor 1.5 for GNU. The meillo@27: largest influence on it are empty lines, pure comment lines meillo@27: and the size of the license block at the beginning of the file. meillo@27: .PP meillo@27: Regarding the variation between logical code lines and the meillo@27: file size (\f(CWwc -c\fP), the implementations span between meillo@27: 25 and 30 bytes per statement. With only 21 bytes per meillo@27: statement, the Heirloom implementation marks the lower end; meillo@27: the GNU implementation sets the upper limit at nearly 40. In meillo@27: the case of GNU, the reason is mainly their coding style, with meillo@27: special indent rules and long identifiers. Whether one finds meillo@27: the Heirloom implementation meillo@27: .[[ http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/cut/cut.c?revision=1.6&view=markup meillo@27: highly cryptic or exceptionally elegant, shall be left meillo@27: open to the judgement of the reader. Especially the meillo@27: comparison to the GNU implementation meillo@27: .[[ http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cut.c;hb=e981643 meillo@27: is impressive. meillo@27: .PP meillo@27: The internal structure of the source code (in all cases it is meillo@27: written in C) is mainly similar. Besides the mandatory main meillo@27: function, which does the command line argument processing, meillo@27: there usually exists a function to convert the field meillo@27: selection specification to an internal data structure. meillo@27: Further more, almost all implementations have separate meillo@27: functions for each of their operation modes. The POSIX-compliant meillo@27: versions treat the \f(CW-b -n\fP combination as a separate meillo@27: mode and thus implement it in an own function. Only the early meillo@27: System III implementation (and its 4.3BSD-UWisc variant) do meillo@27: everything, apart from error handling, in the main function. meillo@27: .PP meillo@27: Implementations of cut typically have two limiting aspects: meillo@27: One being the maximum number of fields that can be handled, meillo@27: the other being the maximum line length. On System III, both meillo@27: numbers are limited to 512. 4.3BSD-Reno and the BSDs of the meillo@27: 90s have fixed limits as well (\f(CW_BSD_LINE_MAX\fP or meillo@27: \f(CW_POSIX2_LINE_MAX\fP). Modern FreeBSD, NetBSD, all GNU meillo@27: implementations and the Heirloom cut is able to handle meillo@27: arbitrary numbers of fields and line lengths \(en the memory meillo@27: is allocated dynamically. OpenBSD cut is a hybrid: It has a fixed meillo@27: maximum number of fields, but allows arbitrary line lengths. meillo@27: The limited number of fields does, however, not appear to be meillo@27: any practical problem, because \f(CW_POSIX2_LINE_MAX\fP is meillo@27: guaranteed to be at least 2048 and is thus probably large enough. meillo@27: meillo@27: .SH meillo@27: Descriptions meillo@27: .LP meillo@27: Interesting, as well, is a comparison of the short descriptions meillo@27: of cut, as can be found in the headlines of the man meillo@27: pages or at the beginning of the source code files. meillo@27: The following list is roughly sorted by time and grouped by meillo@27: decent: meillo@27: .TS meillo@27: center; meillo@27: l l. meillo@27: CB UNIX cut out selected fields of each line of a file meillo@27: System III cut out selected fields of each line of a file meillo@27: System III \(dg cut and paste columns of a table (projection of a relation) meillo@27: System V cut out selected fields of each line of a file meillo@27: HP-UX cut out (extract) selected fields of each line of a file meillo@27: .sp .3 meillo@27: 4.3BSD-UWisc \(dg cut and paste columns of a table (projection of a relation) meillo@27: 4.3BSD-Reno select portions of each line of a file meillo@27: NetBSD select portions of each line of a file meillo@27: OpenBSD 4.6 select portions of each line of a file meillo@27: FreeBSD 1.0 select portions of each line of a file meillo@27: FreeBSD 10.0 cut out selected portions of each line of a file meillo@27: SunOS 4.1.3 remove selected fields from each line of a file meillo@27: SunOS 5.5.1 cut out selected fields of each line of a file meillo@27: .sp .3 meillo@27: Heirloom Tools cut out selected fields of each line of a file meillo@27: Heirloom Tools \(dg cut out fields of lines of files meillo@27: .sp .3 meillo@27: GNU coreutils remove sections from each line of files meillo@27: .sp .3 meillo@27: Minix select out columns of a file meillo@27: .sp .3 meillo@27: Version 8 Unix rearrange columns of data meillo@27: ``Unix Reader'' rearrange columns of text meillo@27: .sp .3 meillo@27: POSIX cut out selected fields of each line of a file meillo@27: .TE meillo@27: .LP meillo@27: (The descriptions that are marked with `\(dg' were taken from meillo@27: source code files. The POSIX entry contains the description meillo@27: used in the standard. The ``Unix Reader'' is a retrospective meillo@27: document by Doug McIlroy, which lists the availability of meillo@27: tools in the Research Unix versions meillo@27: .[[ http://doc.cat-v.org/unix/unix-reader/contents.pdf . meillo@27: Its description should actually match the one in Version 8 meillo@27: Unix. The change could be a transfer mistake or a correction. meillo@27: All other descriptions originate from the various man pages.) meillo@27: .PP meillo@27: Over time, the POSIX description was often adopted or it meillo@27: served as inspiration. One such example is FreeBSD meillo@27: .[[ https://svnweb.freebsd.org/base?view=revision&revision=167101 . meillo@27: .PP meillo@27: It is noteworthy that the GNU coreutils in all versions meillo@27: describe the performed action as a removal of parts of the meillo@27: input, although the user clearly selects the parts that are meillo@27: output. Probably the words ``cut out'' are too misleading. meillo@27: HP-UX concretized them. meillo@27: .PP meillo@27: There are also different terms used for the thing being meillo@27: selected. Some talk about fields (POSIX), some talk meillo@27: about portions (BSD) and some call it columns (Research meillo@27: Unix). meillo@27: .PP meillo@27: The seemingly least adequate description, the one of Version meillo@27: 8 Unix (``rearrange columns of data'') is explainable in so meillo@27: far that the man page covers both, cut and paste, and in meillo@27: their combination, columns can be rearranged. The use of meillo@27: ``data'' instead of ``text'' might be a lapse, which McIlroy meillo@27: corrected in his Unix Reader ... but, on the other hand, on meillo@27: Unix, the two words are mostly synonymous, because all data meillo@27: is text. meillo@27: meillo@27: meillo@27: .SH meillo@27: Referenzen meillo@27: .LP meillo@27: .nf meillo@27: ._r meillo@27: