fix numerous grammer issues

1 files changed, 29 insertions, 27 deletions

diff --git a/usr.bin/locate/locate/locate.1 b/usr.bin/locate/locate/locate.1
index bbc81305709..77d12112b85 100644
--- a/usr.bin/locate/locate/locate.1
+++ b/usr.bin/locate/locate/locate.1
@@ -1,4 +1,4 @@
-.\"	$OpenBSD: locate.1,v 1.5 1996/10/20 00:52:56 michaels Exp $
+.\"	$OpenBSD: locate.1,v 1.6 1998/08/12 07:25:33 deraadt Exp $
 .\"
 .\" Copyright (c) 1995 Wolfram Schneider <wosch@FreeBSD.org>. Berlin.
 .\" Copyright (c) 1990, 1993
@@ -33,7 +33,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)locate.1	8.1 (Berkeley) 6/6/93
-.\"	$Id: locate.1,v 1.5 1996/10/20 00:52:56 michaels Exp $
+.\"	$Id: locate.1,v 1.6 1998/08/12 07:25:33 deraadt Exp $
 .\"
 .Dd June 6, 1993
 .Dt LOCATE 1
@@ -48,7 +48,7 @@
 .Op Fl d Ar database 
 pattern ...
 .Sh DESCRIPTION
-.Nm Locate
+.Nm locate
 searches a database for all pathnames which match the specified
 .Ar pattern  .
 The database is recomputed periodically (usually weekly or daily), 
@@ -68,11 +68,11 @@ including slashes (``/'').
 As a special case, a pattern containing no globbing characters (``foo'')
 is matched as though it were ``*foo*''.
 
-Historically, locate store only characters between 32 and 127.  The
-current implementation store any character except newline ('\\n') and
-NUL ('\\0'). The 8-bit character support don't wast extra space for
-plain ASCII file names. Characters less than 32 or greather than 127
-are stored in 2 bytes.
+Historically, locate stores only characters between 32 and 127.  The
+current implementation store all characters except newline ('\\n') and
+NUL ('\\0'). The 8-bit character support does not waste extra space for
+plain ASCII file names.  Characters less than 32 or greather than 127
+are stored as 2 bytes.
 
 The following options are available:
 .Bl -tag -width 10n indent
@@ -178,40 +178,42 @@ option was specified.
 .Sh BUGS
 .Nm
 may fail to list some files that are present, or may 
-to list files that have been removed from the system.  This is because
-locate only reports files that are present in the database, which is
-typically only regenerated once a week by the 
+list files that have been removed from the system.  This is because
+.Nm
+only reports files that are present in a periodically reconstructed
+database (typically rebuilt once a week by the
 .Pa /etc/weekly 
-script.  Use
+script).
+Use
 .Xr find 1
 to locate files that are of a more transitory nature.
 
+The
 .Nm
-database was built by user 
-.Dq nobody .
-.Xr find 1
-skip directories,
-which are not readable for user 
+database is built by user
+.Dq nobody
+using
+.Xr find 1 .
+This will
+skip directories which are not readable by user
 .Dq nobody , 
 group
 .Dq nobody ,
 or
-world. E.g. if your HOME directory ist not world-readable, all your
-files are 
+the world.
+E.g. if your HOME directory is not world-readable, your files will
 .Ar not
-in the database.
+appear in the database.
 
 The
 .Nm
-database is not byte order independ. It is not possible
+database is not byte order independent. It is not possible
 to share the databases between machines with different byte order.
-The current 
+The current
 .Nm
-implementation understand databases in host byte order or
-network byte order. So you can read on a FreeBSD/i386 machine 
-(little endian)
-a locate database which was built on SunOS/sparc machine
-(big endian, net).
+implementation understands databases in host byte order or
+network byte order.  So a little-endian machine can understand
+a locate database which was built on an big-endian machine.
 
 .Sh HISTORY
 The