[PATCH 26/37] Manual typos: System Databases and Name Service Switch

[ricaljasan at pacific dot net]

2016-05-06  Rical Jasan  <ricaljasan@pacific.net>

	* manual/nss.texi: Fix typos in the manual.
---
 manual/nss.texi |   44 ++++++++++++++++++++++----------------------
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/manual/nss.texi b/manual/nss.texi
index 66dccef..fd479d4 100644
--- a/manual/nss.texi
+++ b/manual/nss.texi
@@ -12,7 +12,7 @@ Network Information Service (NIS) and the Domain Name Service (DNS))
 became popular, and were hacked into the C library, usually with a fixed
 search order.
 
-@Theglibc{} contains a cleaner solution of this problem.  It is
+@Theglibc{} contains a cleaner solution to this problem.  It is
 designed after a method used by Sun Microsystems in the C library of
 @w{Solaris 2}.  @Theglibc{} follows their name and calls this
 scheme @dfn{Name Service Switch} (NSS).
@@ -46,7 +46,7 @@ The modules can be updated separately.
 The C library image is smaller.
 @end enumerate
 
-To fulfill the first goal above the ABI of the modules will be described
+To fulfill the first goal above, the ABI of the modules will be described
 below.  For getting the implementation of a new service right it is
 important to understand how the functions in the modules get called.
 They are in no way designed to be used by the programmer directly.
@@ -106,7 +106,7 @@ There will be some more added later (@code{automount}, @code{bootparams},
 @cindex @file{nsswitch.conf}
 Somehow the NSS code must be told about the wishes of the user.  For
 this reason there is the file @file{/etc/nsswitch.conf}.  For each
-database this file contain a specification how the lookup process should
+database, this file contains a specification of how the lookup process should
 work.  The file could look like this:
 
 @example
@@ -141,7 +141,7 @@ the reaction on lookup result like @code{[NOTFOUND=return]}.
 The above example file mentions five different services: @code{files},
 @code{db}, @code{dns}, @code{nis}, and @code{nisplus}.  This does not
 mean these
-services are available on all sites and it does also not mean these are
+services are available on all sites and neither does it mean these are
 all the services which will ever be available.
 
 In fact, these names are simply strings which the NSS code uses to find
@@ -279,8 +279,8 @@ and the default value for the three databases above is
 @code{compat [NOTFOUND=return] files}.
 
 For all other databases the default value is
-@code{nis [NOTFOUND=return] files}.  This solution give the best
-chance to be correct since NIS and file based lookup is used.
+@code{nis [NOTFOUND=return] files}.  This solution gives the best
+chance to be correct since NIS and file based lookups are used.
 
 @cindex optimizing NSS
 A second point is that the user should try to optimize the lookup
@@ -316,7 +316,7 @@ interested in this topic should read about Dynamic Linking.
 @subsection The Naming Scheme of the NSS Modules
 
 @noindent
-The name of each function consist of various parts:
+The name of each function consists of various parts:
 
 @quotation
        _nss_@var{service}_@var{function}
@@ -349,7 +349,7 @@ functions.  I.e., if the user would call the @code{gethostbyname_r}
 function this also would end in the above function.  For all user
 interface functions the C library maps this call to a call to the
 reentrant function.  For reentrant functions this is trivial since the
-interface is (nearly) the same.  For the non-reentrant version The
+interface is (nearly) the same.  For the non-reentrant version the
 library keeps internal buffers which are used to replace the user
 supplied buffer.
 
@@ -379,7 +379,7 @@ not starting with @file{lib} but don't tell this to anybody.}
 Now we know about the functions contained in the modules.  It is now
 time to describe the types.  When we mentioned the reentrant versions of
 the functions above, this means there are some additional arguments
-(compared with the standard, non-reentrant version).  The prototypes for
+(compared with the standard, non-reentrant versions).  The prototypes for
 the non-reentrant and reentrant versions of our function above are:
 
 @smallexample
@@ -430,7 +430,7 @@ necessary the source code should be examined to learn about the details.
 
 In case the interface function has to return an error it is important
 that the correct error code is stored in @code{*@var{errnop}}.  Some
-return status value have only one associated error code, others have
+return status values have only one associated error code, others have
 more.
 
 @multitable @columnfractions .3 .2 .50
@@ -461,7 +461,7 @@ These are proposed values.  There can be other error codes and the
 described error codes can have different meaning.  @strong{With one
 exception:} when returning @code{NSS_STATUS_TRYAGAIN} the error code
 @code{ERANGE} @emph{must} mean that the user provided buffer is too
-small.  Everything is non-critical.
+small.  Everything else is non-critical.
 
 The above function has something special which is missing for almost all
 the other module functions.  There is an argument @var{h_errnop}.  This
@@ -609,7 +609,7 @@ This function simply closes all files which are still open or removes
 buffer caches.  If there are no files or buffers to remove this is again
 a simple noop.
 
-There normally is no return value different to @var{NSS_STATUS_SUCCESS}.
+There normally is no return value other than @var{NSS_STATUS_SUCCESS}.
 
 @item enum nss_status _nss_@var{database}_get@var{db}ent_r (@var{STRUCTURE} *result, char *buffer, size_t buflen, int *errnop)
 Since this function will be called several times in a row to retrieve
@@ -628,12 +628,12 @@ guaranteed that the same buffer will be passed for the next call of this
 function.  Therefore one must not misuse this buffer to save some state
 information from one call to another.
 
-Before the function returns the implementation should store the value of
-the local @var{errno} variable in the variable pointed to be
-@var{errnop}.  This is important to guarantee the module working in
+Before the function returns, the implementation should store the value of
+the local @var{errno} variable in the variable pointed to by
+@var{errnop}.  This is important to guarantee the module works in
 statically linked programs.
 
-As explained above this function could also have an additional last
+As explained above, this function could also have an additional last
 argument.  This depends on the database used; it happens only for
 @code{host} and @code{networks}.
 
@@ -642,7 +642,7 @@ more entries.  When the last entry was read it should return
 @code{NSS_STATUS_NOTFOUND}.  When the buffer given as an argument is too
 small for the data to be returned @code{NSS_STATUS_TRYAGAIN} should be
 returned.  When the service was not formerly initialized by a call to
-@code{_nss_@var{DATABASE}_set@var{db}ent} all return value allowed for
+@code{_nss_@var{DATABASE}_set@var{db}ent} all return values allowed for
 this function can also be returned here.
 
 @item enum nss_status _nss_@var{DATABASE}_get@var{db}by@var{XX}_r (@var{PARAMS}, @var{STRUCTURE} *result, char *buffer, size_t buflen, int *errnop)
@@ -653,17 +653,17 @@ interface functions.  All arguments given to the non-reentrant version
 are here described by @var{PARAMS}.
 
 The result must be stored in the structure pointed to by @var{result}.
-If there is additional data to return (say strings, where the
+If there are additional data to return (say strings, where the
 @var{result} structure only contains pointers) the function must use the
-@var{buffer} or length @var{buflen}.  There must not be any references
+@var{buffer} of length @var{buflen}.  There must not be any references
 to non-constant global data.
 
 The implementation of this function should honor the @var{stayopen}
 flag set by the @code{set@var{DB}ent} function whenever this makes sense.
 
-Before the function returns the implementation should store the value of
-the local @var{errno} variable in the variable pointed to be
-@var{errnop}.  This is important to guarantee the module working in
+Before the function returns, the implementation should store the value of
+the local @var{errno} variable in the variable pointed to by
+@var{errnop}.  This is important to guarantee the module works in
 statically linked programs.
 
 Again, this function takes an additional last argument for the