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@28: is such a nice and useful tool with good explanatory value. meillo@28: This text shall take a look underneath its surface. meillo@27: .SH meillo@27: Usage meillo@27: .LP meillo@28: Initially, cut had two operation modes, which were later amended meillo@28: by a third: The cut program may cut specified characters or bytes meillo@28: out of the input lines or it may cut out specified fields, which meillo@28: are defined 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@28: rights from the output of \f(CWls -l\fP, as shown here with the meillo@28: rights of a 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@28: 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@28: "%.10s\\n" "$long"\fP for this task.) meillo@27: .PP meillo@28: However, if it's not about displaying characters, but rather about meillo@28: storing them, then \f(CW-c\fP is only partly suited. In former times, meillo@28: when US-ASCII was the omnipresent character encoding, each meillo@28: character was stored as exactly one byte. Therefore, \f(CWcut meillo@28: -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@28: was added to cut, with POSIX.2-1992. To select up to 500 bytes meillo@28: from the beginning 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@28: function of cut is important for POSIX, because it provides a meillo@28: transformation of text files with arbitrary line lenghts to text meillo@28: files with limited line length meillo@27: .[[ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 . meillo@27: .PP meillo@28: The introduction of the new byte mode essentially held the same meillo@28: functionality as the old character mode. The character mode, meillo@28: however, required a new, different implementation. In consequence, meillo@28: the problem was not the support of the byte mode, but rather the meillo@28: correct support of the new character mode. meillo@27: .PP meillo@28: Besides the character and byte modes, cut also offers a field meillo@28: mode, which is activated by \f(CW-f\fP. It selects fields from meillo@28: the input. The field-delimiter character for the input as well meillo@28: as for the output (by default the tab) may be changed using meillo@28: \f(CW-d\fP. 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@28: instance, the usernames and their uids: 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@28: passwd file. Beyond that, it soon reaches its limits. The typical meillo@28: case of whitespace-separated fields, in particular, is covered meillo@28: poorly by it. Cut's delimiter is exactly one character, meillo@28: 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@28: Awk provides another functionality that cut lacks: 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@28: fields occur multiple times. Thus, the invocation meillo@27: \f(CWcut -c 5-8,1,4-6\fP outputs the characters number meillo@28: 1, 4, 5, 6, 7, and 8 in exactly this order. The meillo@28: selection specification resembles 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@28: This means that cut applies the \fIprojection\fP database operation 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@28: This is the oldest implementation of the program I was able to meillo@28: discover. However, the SCCS-ID in the source code contains the meillo@28: version number 1.5. According to Doug McIlroy meillo@27: .[[ http://minnie.tuhs.org/pipermail/tuhs/2015-May/004083.html , meillo@28: the earlier history likely lies 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@28: for marketing purposes only; it is otherwise identical to it. A meillo@28: branch 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@28: contains the earliest mention of cut that my research brought meillo@28: to light, in the form of a man page meillo@27: .[[ ftp://sunsite.icm.edu.pl/pub/unix/UnixArchive/PDP-11/Distributions/other/CB_Unix/cbunix_man1_02.pdf . meillo@27: .PP meillo@28: A look at 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@28: The subsequent 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@28: The code does have 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@28: 1992. It is unclear why the years until 1997, at least from meillo@28: 1992 onwards, 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@28: being a decade older than Linux (the kernel), Unix was present meillo@28: for over ten years by the time 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@28: tools sed and awk were part of it already. Hence, the meillo@28: question comes to mind why cut was written at all, as two meillo@28: programs already existed that were able to cover the use cases of meillo@28: cut. One reason for cut surely was its compactness and the meillo@28: 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@28: well! Cut was sufficiently convincing. It found its way to meillo@28: other Unix variants, it became standardized, and today it is meillo@28: present everywhere. meillo@27: .PP meillo@28: The original variant (without \f(CW-b\fP) was described already meillo@28: in 1985, by the System V Interface Definition, an important meillo@28: formal description of UNIX System V. In the following years, it meillo@28: appeared in all relevant standards. POSIX.2 specified cut for meillo@28: the first time in its modern form (with \f(CW-b\fP) in 1992. meillo@27: meillo@27: .SH meillo@27: Multi-byte support meillo@27: .LP meillo@28: The byte mode and thus the multi-byte support of the POSIX meillo@28: character mode have benn standardized since 1992. But meillo@27: how about their presence in the available implementations? meillo@28: Which versions implement POSIX correctly? meillo@27: .PP meillo@28: The situation is divided into three parts: There are historic meillo@27: implementations, which have only \f(CW-c\fP and \f(CW-f\fP. meillo@28: Then there are implementations that 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@28: that implement \f(CW-c\fP and \f(CW-b\fP in a POSIX-compliant meillo@28: way. meillo@27: .PP meillo@27: Historic two-mode implementations are the ones of meillo@28: System III, System V, and the BSD ones until the mid-90s. meillo@27: .PP meillo@28: Pseudo multi-byte implementations are provided by GNU, meillo@28: modern NetBSD, and modern 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@28: encodings, at least they declare that clearly: meillo@27: .QP meillo@28: Since we don't support multi-byte characters, the \f(CW-c\fP meillo@28: and \f(CW-b\fP options are equivalent, and the \f(CW-n\fP meillo@28: 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@28: conforming to POSIX, in the summer of 2004 meillo@27: .[[ https://svnweb.freebsd.org/base?view=revision&revision=131194 . meillo@28: The question why the other BSD systems have not meillo@28: integrated this change is an open one. Maybe the answer an be meillo@27: found in the above quoted statement. meillo@27: .PP meillo@28: How does a user find out if the cut on their own system handles meillo@28: multi-byte characters correctly? 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@28: symbol, and check if one or more bytes are generated as meillo@28: 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@28: In this case it resulted in two bytes: octal 303 and 244. (The meillo@28: 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@28: Now for the test of the cut implementation. On a UTF-8 system, a meillo@28: 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@28: A pseudo-POSIX implementation, in contrast, behaves like the meillo@28: middle one for all three invocations: Only the first byte is meillo@28: printed as 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@28: impression. Typically, it grows through time. This can generally meillo@28: be seen here, but not in all cases. A POSIX-compliant meillo@27: implementation of the character mode requires more code, thus meillo@28: these implementations tend to be 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@28: implementations, 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@28: 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@28: lines (SLOC, measured with SLOCcount) and the number of meillo@28: 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@28: 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@28: the GNU implementation sets the upper limit at nearly 40 bytes. In meillo@27: the case of GNU, the reason is mainly their coding style, with meillo@28: special indentation 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@28: highly cryptic or exceptionally elegant shall be left meillo@28: 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@28: there usually is a function to convert the field meillo@27: selection specification to an internal data structure. meillo@28: Furthermore, 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@28: mode and thus implement it in a separate 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@28: \f(CW_POSIX2_LINE_MAX\fP). Modern FreeBSD, modern NetBSD, all GNU meillo@28: implementations, and the Heirloom cut are 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@28: The limited number of fields does not, however, 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@28: The following list is roughly grouped by origin: 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@28: input, although the user clearly selects the parts that then meillo@28: consistute the output. Probably the words ``cut out'' are too meillo@28: misleading. HP-UX tried to be more clear. meillo@27: .PP meillo@28: Different terms are also used for the part 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@28: 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@28: 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@28: References meillo@27: .LP meillo@27: .nf meillo@27: ._r meillo@27: