The following patch makes some corrections to mksh.1:

thich -> which
prefices -> prefixes
parametres -> parameters
subtile -> subtle
same-numer -> same-number

One could argue about the inclusion of 'prefices' but I think,
on balance, prefixes is 'more' correct.

I'm grasping at straws on 'same-numer': I can only assume it
should be 'number'.

(The use of 'derivates' in the 'AUTHORS' section is, IMHO, pushing it. I
really think it should be 'derivatives', but upon such quibbles have wars
been fought. The use of the word 'arithmetics' makes me wonder.)

--- mksh.1.rev  2016-10-13 22:15:02.000000000 +0100
+++ mksh.1      2016-10-13 22:15:10.000000000 +0100
@@ -1062,7 +1062,7 @@
 .Ql \eu#### ,
 .Dq #
-means a hexadecimal digit, of thich there may be none up to four or eight;
+means a hexadecimal digit, of which there may be none up to four or eight;
 these escapes translate a Unicode codepoint to UTF-8.
 .Ql \eE
@@ -3188,7 +3188,7 @@
 .Ar substitute
 string which may contain editing commands but not other macros.
 If a tilde postfix is given, a tilde trailing the one or
-two prefices and the control character is ignored, any
+two prefixes and the control character is ignored, any
 other trailing character will be processed afterwards.
 Control characters may be written using caret notation
@@ -4936,7 +4936,7 @@
 .Ar name
 is accessed.
 This can be used by functions to access variables whose names are
-passed as parametres, instead of using
+passed as parameters, instead of using
 .Ic eval .
 .It Fl p
 Print complete
@@ -6643,7 +6643,7 @@
 has a different scope model from
 .Nm ksh ,
-which leads to subtile differences in semantics for identical builtins.
+which leads to subtle differences in semantics for identical builtins.
 This can cause issues with a
 .Ic nameref
 to suddenly point to a local variable by accident; fixing this is hard.
@@ -6715,7 +6715,7 @@
 does not free old history entries (leaks memory) and leaks
 old entries into the new history if their line numbers are
-not overwritten by same-numer entries from the persistent
+not overwritten by same-number entries from the persistent
 history file; truncating the on-disc file to
 lines has always been broken and prone to history file corruption

Reply via email to