1.1 --- a/cut.en.ms	Sat Sep 12 13:13:21 2015 +0200
     1.2 +++ b/cut.en.ms	Tue Sep 15 17:20:20 2015 +0200
     1.3 @@ -90,7 +90,7 @@
     1.4  \f(CW-d\fP.
     1.5  .PP
     1.6  The typical example for the use of cut's field mode is the
     1.7 -selection of information from the passwd file. Here, for
     1.8 +selection of information from the password file. Here, for
     1.9  instance, the usernames and their uids:
    1.10  .CS
    1.11  	$ cut -d: -f1,3 /etc/passwd
    1.12 @@ -105,7 +105,7 @@
    1.13  to them or separated by whitespace.)
    1.14  .PP
    1.15  The field mode is suited for simple tabulary data, like the
    1.16 -passwd file. Beyond that, it soon reaches its limits. The typical
    1.17 +password file. Beyond that, it soon reaches its limits. The typical
    1.18  case of whitespace-separated fields, in particular, is covered
    1.19  poorly by it. Cut's delimiter is exactly one character,
    1.20  therefore one can not split at both space and tab characters.
    1.21 @@ -205,7 +205,7 @@
    1.22  	Copyright (C) 1984 David M. Ihnat
    1.23  .CE
    1.24  .LP
    1.25 -The code does have old origins. Further comments show that
    1.26 +This code does have old origins. Further comments show that
    1.27  the source code was reworked by David MacKenzie first and later
    1.28  by Jim Meyering, who put it into the version control system in
    1.29  1992. It is unclear why the years until 1997, at least from
    1.30 @@ -214,13 +214,13 @@
    1.31  Despite all those year numbers from the 80s, cut is a rather
    1.32  young tool, at least in relation to the early Unix. Despite
    1.33  being a decade older than Linux (the kernel), Unix was present
    1.34 -for over ten years by the time cut appeared for the first
    1.35 +for over ten years already by the time cut appeared for the first
    1.36  time. Most notably, cut wasn't part of Version 7 Unix, which
    1.37  became the basis for all modern Unix systems. The more complex
    1.38  tools sed and awk were part of it already. Hence, the
    1.39  question comes to mind why cut was written at all, as two
    1.40 -programs already existed that were able to cover the use cases of
    1.41 -cut. One reason for cut surely was its compactness and the
    1.42 +programs already existed that were able to cover its use
    1.43 +cases. One reason for cut surely was its compactness and the
    1.44  resulting speed, in comparison to the then-bulky awk. This lean
    1.45  shape goes well with the Unix philosopy: Do one job and do it
    1.46  well! Cut was sufficiently convincing. It found its way to
    1.47 @@ -253,8 +253,7 @@
    1.48  way.
    1.49  .PP
    1.50  Historic two-mode implementations are the ones of
    1.51 -System III, System V, and the BSD ones from the beginning
    1.52 -until the mid-90s.
    1.53 +System III, System V, and the BSD ones until the mid-90s.
    1.54  .PP
    1.55  Pseudo multi-byte implementations are provided by GNU,
    1.56  modern NetBSD, and modern OpenBSD. The level of POSIX compliance
    1.57 @@ -270,9 +269,9 @@
    1.58  option is meaningless.
    1.59  .[[ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup
    1.60  .LP
    1.61 -Standard-adhering implementations, ones that treat
    1.62 -multi-byte characters correctly, are the one of the modern
    1.63 -FreeBSD and the one in the Heirloom toolchest. Tim Robbins
    1.64 +Standard-adhering implementations, i.e. ones that treat
    1.65 +multi-byte characters correctly, are those of the modern
    1.66 +FreeBSD and the Heirloom toolchest. Tim Robbins
    1.67  reimplemented the character mode of FreeBSD cut,
    1.68  conforming to POSIX, in the summer of 2004
    1.69  .[[ https://svnweb.freebsd.org/base?view=revision&revision=131194 .
    1.70 @@ -280,7 +279,7 @@
    1.71  integrated this change is an open one. Maybe the answer an be
    1.72  found in the above quoted statement.
    1.73  .PP
    1.74 -How does a user find out if the cut on their own system handles
    1.75 +How do users find out if the cut on their own system handles
    1.76  multi-byte characters correctly? First, one needs to check if
    1.77  the system itself uses multi-byte characters, because otherwise
    1.78  characters and bytes are equivalent and the question
    1.79 @@ -347,7 +346,7 @@
    1.80  .TS
    1.81  center;
    1.82  r r r l l l.
    1.83 -SLOC	Lines	Bytes	Belongs to  	File tyime	Category
    1.84 +SLOC	Lines	Bytes	Belongs to  	File time	Category
    1.85  _
    1.86  116	123	 2966	System III	1980-04-11	historic
    1.87  118	125	 3038	4.3BSD-UWisc	1986-11-07	historic
    1.88 @@ -362,7 +361,7 @@
    1.89  588	830	23167	GNU coreutils	2015-05-01	pseudo-POSIX
    1.90  .TE
    1.91  .LP
    1.92 -Roughly four groups can be seen: (1) The two original
    1.93 +There are four rough groups: (1) The two original
    1.94  implementations, which are mostly identical, with about 100
    1.95  SLOC. (2) The five BSD versions, with about 200 SLOC. (3) The
    1.96  two POSIX-compliant versions and the old GNU one, with a SLOC