docs/cut
diff cut.en.ms @ 33:a1589fcfe9f4
spell-checking plus a clarification thanks to Francesc
author | markus schnalke <meillo@marmaro.de> |
---|---|
date | Fri, 02 Oct 2015 07:01:20 +0200 |
parents | 5f78bcd34eeb |
children | 04a3cdadc50c |
line diff
1.1 --- a/cut.en.ms Fri Sep 18 10:28:29 2015 +0200 1.2 +++ b/cut.en.ms Fri Oct 02 07:01:20 2015 +0200 1.3 @@ -73,7 +73,7 @@ 1.4 .LP 1.5 The remainder can be caught with \f(CWcut -b 501-\fP. This 1.6 use of cut is important for POSIX, because it provides a 1.7 -transformation of text files with arbitrary line lenghts to text 1.8 +transformation of text files with arbitrary line lengths to text 1.9 files with limited line length 1.10 .[[ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 . 1.11 .PP 1.12 @@ -104,7 +104,7 @@ 1.13 (The values to the command line switches may be appended directly 1.14 to them or separated by whitespace.) 1.15 .PP 1.16 -The field mode is suited for simple tabulary data, like the 1.17 +The field mode is suited for simple tabular data, like the 1.18 password file. Beyond that, it soon reaches its limits. The typical 1.19 case of whitespace-separated fields, in particular, is covered 1.20 poorly by it. Cut's delimiter is exactly one character, 1.21 @@ -222,7 +222,7 @@ 1.22 programs already existed that were able to cover its use 1.23 cases. One reason for cut surely was its compactness and the 1.24 resulting speed, in comparison to the then-bulky awk. This lean 1.25 -shape goes well with the Unix philosopy: Do one job and do it 1.26 +shape goes well with the Unix philosophy: Do one job and do it 1.27 well! Cut was sufficiently convincing. It found its way to 1.28 other Unix variants, it became standardized, and today it is 1.29 present everywhere. 1.30 @@ -276,8 +276,8 @@ 1.31 conforming to POSIX, in the summer of 2004 1.32 .[[ https://svnweb.freebsd.org/base?view=revision&revision=131194 . 1.33 The question why the other BSD systems have not 1.34 -integrated this change is an open one. Maybe the answer can be 1.35 -found in the above quoted statement. 1.36 +integrated this change is an open one. Maybe the answer is 1.37 +a general ignorance of internationalization. 1.38 .PP 1.39 How do users find out if the cut on their own system handles 1.40 multi-byte characters correctly? First, one needs to check if