delete doubled words, e.g.: "the the" -> "the"

8 files changed, 17 insertions, 10 deletions

diff --git a/share/doc/papers/diskperf/conclusions.ms b/share/doc/papers/diskperf/conclusions.ms
index 5381106..b8e9ff3 100644
--- a/share/doc/papers/diskperf/conclusions.ms
+++ b/share/doc/papers/diskperf/conclusions.ms
@@ -30,6 +30,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)conclusions.ms	6.2 (Berkeley) 4/16/91
+.\"	$Id$
 .\"
 .ds RH Conclusions
 .NH
@@ -58,7 +59,7 @@ against the future value and expandability of newer technologies.
 Two important conclusions about storage systems in general
 can be drawn from these tests.
 The first is that buffering can be effective in smoothing
-the the effects of lower bus speeds and bus contention.
+the effects of lower bus speeds and bus contention.
 Even though the UDA50 is located on the relatively slow
 UNIBUS, its performance is similar to controllers located on
 the faster processor busses.
diff --git a/share/doc/papers/diskperf/tests.ms b/share/doc/papers/diskperf/tests.ms
index 1809afe..e507408 100644
--- a/share/doc/papers/diskperf/tests.ms
+++ b/share/doc/papers/diskperf/tests.ms
@@ -30,6 +30,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)tests.ms	6.2 (Berkeley) 4/16/91
+.\"	$Id$
 .\"
 .ds RH Tests
 .NH
@@ -39,7 +40,7 @@ Our battery of tests consists of four programs,
 read_8192, write_8192, write_4096
 and rewrite_8192 originally written by [McKusick83]
 to evaluate the performance of the new file system in 4.2BSD.
-These programs all follow the the same model and are typified by
+These programs all follow the same model and are typified by
 read_8192 shown here.
 .DS
 #define	BUFSIZ 8192
diff --git a/share/doc/papers/fsinterface/fsinterface.ms b/share/doc/papers/fsinterface/fsinterface.ms
index c5722e6..b1cc43e 100644
--- a/share/doc/papers/fsinterface/fsinterface.ms
+++ b/share/doc/papers/fsinterface/fsinterface.ms
@@ -30,6 +30,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)fsinterface.ms	1.4 (Berkeley) 4/16/91
+.\"	$Id$
 .\"
 .if \nv .rm CM
 .de UX
@@ -250,7 +251,7 @@ otherwise, the inode describes the next directory to be searched.
 The inode returned may be used in various ways by the caller;
 it may be examined, the file may be read or written,
 types and access may be checked, and fields may be modified.
-Modified inodes are automatically written back the the filesystem
+Modified inodes are automatically written back the filesystem
 on disk when the last reference is released with \fIiput\fP.
 Although the details are considerably different,
 the same general scheme is used in the faster filesystem in 4.2BSD
@@ -578,7 +579,7 @@ and they may be accessed using short offsets from a base pointer
 .PP
 The proposed filesystem interface is described very tersely here.
 For the most part, data structures and procedures are analogous
-to those used by VFS, and only the changes will be be treated here.
+to those used by VFS, and only the changes will be treated here.
 See [Kleiman86] for complete descriptions of the vfs and vnode operations
 in Sun's interface.
 .PP
diff --git a/share/doc/papers/kernmalloc/kernmalloc.t b/share/doc/papers/kernmalloc/kernmalloc.t
index 62df1b4..0b8bb08 100644
--- a/share/doc/papers/kernmalloc/kernmalloc.t
+++ b/share/doc/papers/kernmalloc/kernmalloc.t
@@ -30,6 +30,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)kernmalloc.t	5.1 (Berkeley) 4/16/91
+.\"	$Id$
 .\"
 .\" reference a system routine name
 .de RN
@@ -600,7 +601,7 @@ Two of the traditional UNIX
 memory allocators remain in the current system.
 The terminal subsystem uses \fIclist\fP\^s (character lists).
 That part of the system is expected to undergo major revision within
-the the next year or so, and it will probably be changed to use
+the next year or so, and it will probably be changed to use
 \fImbuf\fP\^s as it is merged into the network system.
 The other major allocator that remains is
 .RN getblk ,
diff --git a/share/doc/papers/kerntune/1.t b/share/doc/papers/kerntune/1.t
index d78c568..88adf40 100644
--- a/share/doc/papers/kerntune/1.t
+++ b/share/doc/papers/kerntune/1.t
@@ -31,13 +31,14 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)1.t	1.2 (Berkeley) 11/8/90
+.\"	$Id$
 .\"
 .ds RH Introduction
 .NH 1
 Introduction
 .PP
 The purpose of this paper is to describe the tools and techniques 
-that are available for improving the performance of the the kernel.
+that are available for improving the performance of the kernel.
 The primary tool used to measure the kernel is the hierarchical
 profiler \fIgprof\fP.
 The profiler enables the user to measure the cost of
diff --git a/share/doc/papers/malloc/kernel.ms b/share/doc/papers/malloc/kernel.ms
index 1a4e967..21dff8d 100644
--- a/share/doc/papers/malloc/kernel.ms
+++ b/share/doc/papers/malloc/kernel.ms
@@ -6,7 +6,7 @@
 .\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 .\" ----------------------------------------------------------------------------
 .\"
-.\" $Id$
+.\" $Id: kernel.ms,v 1.1 1996/04/13 08:30:16 phk Exp $
 .\"
 .ds RH The kernel and memory
 .NH
@@ -30,7 +30,7 @@ for the data and bss section combined and one for the stack.
 On some systems the text shared a segment with the data and bss, and was
 consequently just as writable as them.
 .PP
-In this setup all the the brk(2) system call have to do is to find the
+In this setup all the brk(2) system call have to do is to find the
 right amount of free storage, possibly moving things around in physical
 memory, maybe even swapping out a segment or two to make space,
 and change the upper limit on the data segment according to the address given.
diff --git a/share/doc/papers/newvm/1.t b/share/doc/papers/newvm/1.t
index 657fc2d..c934b97 100644
--- a/share/doc/papers/newvm/1.t
+++ b/share/doc/papers/newvm/1.t
@@ -30,6 +30,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)1.t	5.1 (Berkeley) 4/16/91
+.\"	$Id$
 .\"
 .NH
 Motivations for a New Virtual Memory System
@@ -156,7 +157,7 @@ be governed by the amount of physical memory.
 .PP
 Another effect of the current technology is that the latency and overhead
 associated with accessing the file system is considerably higher
-since the access must be be over the network
+since the access must be over the network
 rather than to a locally-attached disk.
 One use of the surplus memory would be to
 maintain a cache of recently used files;
diff --git a/share/doc/papers/newvm/a.t b/share/doc/papers/newvm/a.t
index 3b6213a..3472470 100644
--- a/share/doc/papers/newvm/a.t
+++ b/share/doc/papers/newvm/a.t
@@ -30,6 +30,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)a.t	5.1 (Berkeley) 4/16/91
+.\"	$Id$
 .\"
 .sp 2
 .ne 2i
@@ -200,7 +201,7 @@ value = mset(sem, wait)
 result int value; semaphore *sem; int wait;
 .DE
 \fIMset\fP indivisibly tests and sets the semaphore \fIsem\fP.
-If the the previous value is zero, the process has acquired the lock
+If the previous value is zero, the process has acquired the lock
 and \fImset\fP returns true immediately.
 Otherwise, if the \fIwait\fP flag is zero,
 failure is returned.