[PATCH] Minor grammatical corrections in manual/nss.texi.

[ricaljasan <ricaljasan at pacific dot net>]

`make info' succeeds on x86_64.

After a great long time of learning how to use git and getting up to
speed on the myriad styles and rules for coding and submission, I
finally have a cohesive set of changes to help improve the manual.
They are basically all grammar-related, but a few are purely for
clarity (like changing the variable name for a service from NAME
to SERVICE).  I avoided any kind of restructuring or new content.

I noticed while reading the archives that our email addresses are
modified in the headers but not in the message body.  In an effort
to not have mine unnecessarily displayed verbatim over the Internet,
I've removed it from the ChangeLog entry below.  I hope that is
acceptable.  Let me know if there is a better way to send the ChangeLog
entry without getting my address posted.  I've noticed some people
don't include the header line at all, but the date is important.

First patch submission to libc-alpha:

Fixes a number of problems with grammar, spelling, and punctuation.
Some introductory clauses have been set apart with commas to enhance
sentence clarity.  Other changes include improper articles and
prepositions, misspelled words, incorrect case and tense, etc.

    * manual/nss.texi: Fix up grammar.

2014-10-04  Rical Jasan  <redacted>

	* manual/nss.texi (Name Service Switch): Fix errors in grammar,
	spelling, and punctuation.

diff --git a/manual/nss.texi b/manual/nss.texi
index bf3e69d..df56c7e 100644
--- a/manual/nss.texi
+++ b/manual/nss.texi
@@ -7,12 +7,12 @@
 
 Various functions in the C Library need to be configured to work
 correctly in the local environment.  Traditionally, this was done by
-using files (e.g., @file{/etc/passwd}), but other nameservices (like the
+using files (e.g., @file{/etc/passwd}), but other name services (like the
 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).
@@ -24,10 +24,10 @@ file names we use as we will see later.
 
 
 @menu
-* NSS Basics::                  What is this NSS good for.
+* NSS Basics::                  What NSS is used for.
 * NSS Configuration File::      Configuring NSS.
-* NSS Module Internals::        How does it work internally.
-* Extending NSS::               What to do to add services or databases.
+* NSS Module Internals::        How NSS works internally.
+* Extending NSS::               How to add services or databases.
 @end menu
 
 @node NSS Basics, NSS Configuration File, Name Service Switch, Name Service Switch
@@ -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.
@@ -68,7 +68,7 @@ The databases available in the NSS are
 @cindex shadow
 @vtable @code
 @item aliases
-Mail aliases
+Mail aliases,
 @comment @pxref{Mail Aliases}.
 @item ethers
 Ethernet numbers,
@@ -78,7 +78,7 @@ Groups of users, @pxref{Group Database}.
 @item hosts
 Host names and numbers, @pxref{Host Names}.
 @item netgroup
-Network wide list of host and users, @pxref{Netgroup Database}.
+Network-wide list of hosts and users, @pxref{Netgroup Database}.
 @item networks
 Network names and numbers, @pxref{Networks Database}.
 @item protocols
@@ -91,7 +91,7 @@ Remote procedure call names and numbers,
 @item services
 Network services, @pxref{Services Database}.
 @item shadow
-Shadow user passwords,
+Shadow user passwords
 @comment @pxref{Shadow Password Database}.
 @end vtable
 
@@ -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 specifies how the lookup process should
 work.  The file could look like this:
 
 @example
@@ -149,10 +149,10 @@ the implicitly addressed functions.  The internal interface will be
 described later.  Visible to the user are the modules which implement an
 individual service.
 
-Assume the service @var{name} shall be used for a lookup.  The code for
-this service is implemented in a module called @file{libnss_@var{name}}.
+Assume the service @var{service} shall be used for a lookup.  The code for
+this service is implemented in a module called @file{libnss_@var{service}}.
 On a system supporting shared libraries this is in fact a shared library
-with the name (for example) @file{libnss_@var{name}.so.2}.  The number
+with the name (for example) @file{libnss_@var{service}.so.2}.  The number
 at the end is the currently used version of the interface which will not
 change frequently.  Normally the user should not have to be cognizant of
 these files since they should be placed in a directory where they are
@@ -284,8 +284,8 @@ chance to be correct since NIS and file based lookup is used.
 
 @cindex optimizing NSS
 A second point is that the user should try to optimize the lookup
-process.  The different service have different response times.
-A simple file look up on a local file could be fast, but if the file
+process.  The different services have different response times.
+A simple file lookup on a local file could be fast, but if the file
 is long and the needed entry is near the end of the file this may take
 quite some time.  In this case it might be better to use the @code{db}
 service which allows fast local access to large data sets.
@@ -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}
@@ -423,14 +423,14 @@ numeric value @code{1}
 Now you see where the action items of the @file{/etc/nsswitch.conf} file
 are used.
 
-If you study the source code you will find there is a fifth value:
+If you study the source code, you will find there is a fifth value:
 @code{NSS_STATUS_RETURN}.  This is an internal use only value, used by a
-few functions in places where none of the above value can be used.  If
-necessary the source code should be examined to learn about the details.
+few functions in places where none of the above values can be used.  If
+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
+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
@@ -451,10 +451,10 @@ The function should be called again with a larger buffer.
 @end multitable
 
 These are proposed values.  There can be other error codes and the
-described error codes can have different meaning.  @strong{With one
+error codes described above can have different meanings.  @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.
+@code{ERANGE} @emph{must} mean that the user-provided buffer is too
+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
@@ -469,8 +469,7 @@ functions in the NSS modules.  But there are others which implement
 the other ways to access system databases (say for the
 password database, there are @code{setpwent}, @code{getpwent}, and
 @code{endpwent}).  These will be described in more detail later.
-Here we give a general way to determine the
-signature of the module function:
+Here, we give a general way to determine the signature of a module function:
 
 @itemize @bullet
 @item
@@ -520,7 +519,7 @@ databases s/he is interested in and leave the rest for later (or
 completely aside).
 
 @menu
-* Adding another Service to NSS::  What is to do to add a new service.
+* Adding another Service to NSS::  How to add a new service.
 * NSS Module Function Internals::  Guidelines for writing new NSS
                                         service functions.
 @end menu
@@ -530,8 +529,8 @@ completely aside).
 
 The sources for a new service need not (and should not) be part of @theglibc{}
 itself.  The developer retains complete control over the
-sources and its development.  The links between the C library and the
-new service module consists solely of the interface functions.
+sources and their development.  The links between the C library and the
+new service module consist solely of the interface functions.
 
 Each module is designed following a specific interface specification.
 For now the version is 2 (the interface in version 1 was not adequate)
@@ -586,12 +585,12 @@ database (e.g., it is @code{pw} for the password database).
 @table @code
 @item enum nss_status _nss_@var{database}_set@var{db}ent (void)
 This function prepares the service for following operations.  For a
-simple file based lookup this means files could be opened, for other
+simple file-based lookup this means files could be opened; for other
 services this function simply is a noop.
 
 One special case for this function is that it takes an additional
 argument for some @var{database}s (i.e., the interface is
-@code{int set@var{db}ent (int)}).  @ref{Host Names}, which describes the
+@code{int set@var{db}ent (int)}).  @xref{Host Names}, which describes the
 @code{sethostent} function.
 
 The return value should be @var{NSS_STATUS_SUCCESS} or according to the
@@ -621,14 +620,14 @@ 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 guarantees the module works in
 statically linked programs.
 
-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}.
+As explained above, this function could also have an additional last
+argument, @var{h_errnop}.  This depends on the database used; it only
+happens for @code{host} and @code{networks}.
 
 The function shall return @code{NSS_STATUS_SUCCESS} as long as there are
 more entries.  When the last entry was read it should return
@@ -648,21 +647,21 @@ 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
 @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 guarantees the module works in
 statically linked programs.
 
 Again, this function takes an additional last argument for the
-@code{host} and @code{networks} database.
+@code{host} and @code{networks} databases, @var{h_errnop}.
 
-The return value should as always follow the rules given above
+The return value should always follow the rules given above
 (@pxref{NSS Modules Interface}).
 
 @end table