* doc/user.xml: Various spelling and consistency fixes.

	* doc/ref.xml: Likewise.
	(exit_remote_shell): Remove, as this procedure is defunct.
	* doc/dejagnu.texi: Regenerate.

4 files changed, 52 insertions, 65 deletions

diff --git a/ChangeLog b/ChangeLog
index 6b6469f..c01ad56 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2011-12-30  Ben Elliston  <bje@gnu.org>
 
+	* doc/user.xml: Various spelling and consistency fixes.
+	* doc/ref.xml: Likewise.
+	(exit_remote_shell): Remove, as this procedure is defunct.
+	* doc/dejagnu.texi: Regenerate.
+
+2011-12-30  Ben Elliston  <bje@gnu.org>
+
 	* config.guess: Update to version 2011-12-29.
 	* config.sub: Update to version 2011-11-11.
 
diff --git a/doc/dejagnu.texi b/doc/dejagnu.texi
index 3d616c5..42dca14 100644
--- a/doc/dejagnu.texi
+++ b/doc/dejagnu.texi
@@ -554,9 +554,9 @@ distribution
 @node A simple project without the GNU autotools, Using autoconf/autoheader/automake, , Create a minimal project; e_g_ calc
 @subsection A simple project without the GNU autotools
 
-The runtest program can be run standalone. All the
+The runtest program can be run stand-alone. All the
 autoconf/automake support is just cause those programs are commonly
-used for other GNU applications. The key to running runtest standalone
+used for other GNU applications. The key to running runtest stand-alone
 is having the local site.exp file setup correctly, which automake
 does.
 
@@ -804,7 +804,7 @@ make[1]: Leaving directory `/home/Dgt/dejagnu.test' make: *** [check-am] Fehler
 Did you see the  line "FAIL:"? The test cases for calc catch the bug in the calc.c file. Fix the error in calc.c later as the following examples assume a unchanged calc.c.
 
 Examine the output files calc.sum and calc.log. Try to
-understand the testcases written in
+understand the test cases written in
 ~/dejagnu.test/testsuite/calc.test/calc.exp. To understand Expect you
 might take a look at the book "Exploring Expect", which is
 an excellent resource for learning and using Expect. (Pub: O'Reilly,
@@ -911,8 +911,9 @@ runtest -v -v -v --tool calc CALC=`pwd`/calc --srcdir ./testsuite
 
 Calling runtest with the '--debug'-flag logs a lot of details to dbg.log where you can analyse it afterwards. 
 
-In all test cases you can temporary adjust the verbosity of information by adding the following Tcl-command to any tcl file that gets loaded by
-dejagnu, for instance, ~/.dejagnurc:
+In all test cases you can temporary adjust the verbosity of
+information by adding the following Tcl command to any Tcl file that
+gets loaded by dejagnu, for instance, ~/.dejagnurc:
 
 @example
 
@@ -947,7 +948,7 @@ Run runtest again and verify the output "calc.log"
 
 Testing remote targets is a lot trickier especially if you are using an
 embedded target
-which has no built in support for things like a compiler, ftp server or a Bash-shell.
+which has no built in support for things like a compiler, FTP server or a Bash-shell.
 Before you can test calc on a remote target you have to acquire a few basics skills.
 
 @menu
@@ -966,7 +967,7 @@ Before you can test calc on a remote target you have to acquire a few basics ski
 The easiest remote host is usually the host you are working on.
 In this example we will use telnet to login in your own workstation.
 For security reasons you should never have a telnet daemon running on
-machine connected on the internet, as password and usernames are transmitted
+machine connected on the Internet, as password and user names are transmitted
 in clear text.
 We assume you know how to setup your machine for a telnet daemon.
 
@@ -1102,7 +1103,7 @@ Have a look at the procedures in /usr/share/dejagnu/remote.exp to have an overvi
 
 Now setup a real target.
 In the following example we assume as target a PowerBook running Debian.
-As above add a test user "dgt", install telnet and FTP servers.
+As above add a test user "dgt", install Telnet and FTP servers.
 In order to distinguish it from the host add the line
 
 @example
@@ -1417,7 +1418,7 @@ itself).
 ``triple'' name as used by @code{configure}. This
 is the type of machine DejaGnu and the tools to be tested are built
 on. For a normal cross this is the same as the host, but for a
-canadian cross, they are separate.
+Canadian cross, they are separate.
 
 @item @code{--host [string]}
 @code{string} is a full configuration
@@ -1434,7 +1435,7 @@ are affected by @code{--host}. In this usage,
 be run on, which may not be the same as the
 @emph{build} machine. If @code{--build}
 is also specified, then @code{--host} refers to the
-machine that the tests wil, be run on, not the machine DejaGnu is run
+machine that the tests will be run on, not the machine DejaGnu is run
 on.
 
 @item @code{--host_board [name]}
@@ -2100,7 +2101,7 @@ that for a centralized testing lab where people have to share a
 target between multiple developers. There are settings for both
 remote targets and remote hosts.  Here's an example of a Master
 Config File (also called the Global config file) for a
-@emph{canadian cross}. A canadian cross is when
+@emph{Canadian cross}. A Canadian cross is when
 you build and test a cross compiler on a machine other than the
 one it's to be hosted on.
 
@@ -2149,7 +2150,7 @@ that all run on this host. For testing on operating systems that
 don't support Expect, DejaGnu can be run on the local build
 machine, and it can connect to the remote host and run all the
 tests for this cross compiler on that host. All the remote OS
-requires is a working telnetd.
+requires is a working Telnet server.
 
 As you can see, all one does is set the variable
 @code{target_list} to the list of targets and options to
@@ -2244,12 +2245,12 @@ comprising of non GPL'd code.
 
 @strong{Note}
 
-Thanks to Dj Delorie for the original paper that
+Thanks to DJ Delorie for the original paper that
 this section is based on.
 @end quotation
 
 DejaGnu also supports running the tests on a remote
-host. To set this up, the remote host needs an ftp server, and a
+host. To set this up, the remote host needs an FTP server, and a
 telnet server. Currently foreign operating systems used as
 remote hosts are VxWorks, VRTX, DOS/Windows 3.1, MacOS and Windows.
 
@@ -2379,7 +2380,7 @@ are optional.
 @section Config File Values
 
 DejaGnu uses a named array in Tcl to hold all the info for
-each machine. In the case of a canadian cross, this means host
+each machine. In the case of a Canadian cross, this means host
 information as well as target information. The named array is
 called @code{target_info}, and it has two indices. The
 following fields are part of the array.
@@ -3323,7 +3324,7 @@ test.
 
 DejaGnu uses a single header file to assist in unit
 testing. As this file also produces its one test state output,
-it can be run standalone, which is very useful for testing on
+it can be run stand-alone, which is very useful for testing on
 embedded systems. This header file has a C and C++ API for the
 test states, with simple totals, and standardized
 output. Because the output has been standardized, DejaGnu can be
@@ -3405,7 +3406,7 @@ suites.
 @node Installing DejaGnu, , Configuring DejaGnu, Installation
 @subsection Installing DejaGnu
 
-To install DejaGnu in your filesystem (either in
+To install DejaGnu in your file system (either in
 @file{/usr/local}, or as specified by your
 @code{--prefix} option to @emph{configure}),
 execute.
@@ -3580,8 +3581,8 @@ configuration.
 @node is3way procedure, ishost procedure, is_remote procedure, Core Internal Procedures
 @subsubsection is3way Procedure
 
-Tests for a canadian cross. This is when the tests will be run
-on a remotely hosted cross compiler. If it is a canadian cross, then
+Tests for a Canadian cross. This is when the tests will be run
+on a remotely hosted cross compiler. If it is a Canadian cross, then
 the result is @emph{1}; otherwise the result is
 @emph{0}.
 
@@ -6082,7 +6083,7 @@ host. This should be used as a replacement for the Tcl command
 @code{exec} as this version utilizes the target config
 info to execute this command on the build machine or a remote
 host. All config information for the remote host must be setup to
-have this command work. If this is a canadian cross, (where we test a
+have this command work. If this is a Canadian cross (where we test a
 cross compiler that runs on a different host then where DejaGnu is
 running) then a connection is made to the remote host and the command
 is executed there. It returns either REMOTERROR (for an error) or the
diff --git a/doc/ref.xml b/doc/ref.xml
index b54d2ff..f8c0150 100644
--- a/doc/ref.xml
+++ b/doc/ref.xml
@@ -65,7 +65,7 @@
     <sect3 id="installing"  xreflabel="Installing DejaGnu">
       <title>Installing &dj;</title>
 
-      <para>To install &dj; in your filesystem (either in
+      <para>To install &dj; in your file system (either in
       <filename>/usr/local</filename>, or as specified by your
       <option>--prefix</option> option to <emphasis>configure</emphasis>),
       execute.</para>
@@ -204,8 +204,8 @@
 	<sect4 id="is3way" xreflabel="is3way procedure">
 	  <title>is3way Procedure</title>
 
-	  <para>Tests for a canadian cross. This is when the tests will be run
-	  on a remotely hosted cross compiler. If it is a canadian cross, then
+	  <para>Tests for a Canadian cross. This is when the tests will be run
+	  on a remotely hosted cross compiler. If it is a Canadian cross, then
 	  the result is <emphasis>1</emphasis>; otherwise the result is
 	  <emphasis>0</emphasis>.</para>
 
@@ -2160,31 +2160,6 @@
           </varlistentry>
 	</variablelist>
 	</sect4>
-
-<!-- FIXME: this doesn't seem to exist anymore
-	<sect4 id="exitremoteshell" xreflabel="exit_remote_shell procedure">
-	  <title>exit_remote_shell Procedure</title>
-
-	  <para></para>
-
-          <funcsynopsis role="tcl">
-          <funcprototype>
-            <funcdef><function>exit_remote_shell</function></funcdef>
-              <paramdef><parameter>spawnid</parameter></paramdef>
-           </funcprototype>
-            </funcsynopsis>
-            <variablelist>
-              <varlistentry>
-                <term><parameter>spawnid</parameter></term>
-                <listitem><para>Exits a remote process started by any
-                of the connection procedures. <symbol>spawnid</symbol>
-                is the result of the connection procedure that started
-                the remote process.</para></listitem>
-           </varlistentry>
-         </variablelist>
-	 </sect4>
--->
-
     </sect3>
 
     <sect3 id="connprocs" xreflabel="connprocs">
@@ -3381,7 +3356,7 @@
 	  <command>exec</command> as this version utilizes the target config
 	  info to execute this command on the build machine or a remote
 	  host. All config information for the remote host must be setup to
-	  have this command work. If this is a canadian cross, (where we test a
+	  have this command work. If this is a Canadian cross (where we test a
 	  cross compiler that runs on a different host then where &dj; is
 	  running) then a connection is made to the remote host and the command
 	  is executed there. It returns either REMOTERROR (for an error) or the
@@ -4772,3 +4747,6 @@ sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:
 -->
+
+<!--  LocalWords:  spawnid
+ -->
diff --git a/doc/user.xml b/doc/user.xml
index 09eb19a..0a8fafa 100644
--- a/doc/user.xml
+++ b/doc/user.xml
@@ -98,9 +98,9 @@ distribution</para>
 
 <sect3><title>A simple project without the GNU autotools</title>
 
-<para>The runtest program can be run standalone. All the
+<para>The runtest program can be run stand-alone. All the
 autoconf/automake support is just cause those programs are commonly
-used for other GNU applications. The key to running runtest standalone
+used for other GNU applications. The key to running runtest stand-alone
 is having the local site.exp file setup correctly, which automake
 does.</para> 
 
@@ -337,7 +337,7 @@ make[1]: Leaving directory `/home/Dgt/dejagnu.test' make: *** [check-am] Fehler
 <para>Did you see the  line &quot;FAIL:&quot;? The test cases for calc catch the bug in the calc.c file. Fix the error in calc.c later as the following examples assume a unchanged calc.c.</para>
 
 <para>Examine the output files calc.sum and calc.log. Try to
-understand the testcases written in
+understand the test cases written in
 ~/dejagnu.test/testsuite/calc.test/calc.exp. To understand Expect you
 might take a look at the book &quot;Exploring Expect&quot;, which is
 an excellent resource for learning and using Expect. (Pub: O'Reilly,
@@ -441,8 +441,9 @@ runtest -v -v -v --tool calc CALC=`pwd`/calc --srcdir ./testsuite
 
 <para>Calling runtest with the '--debug'-flag logs a lot of details to dbg.log where you can analyse it afterwards. </para>
 
-<para>In all test cases you can temporary adjust the verbosity of information by adding the following Tcl-command to any tcl file that gets loaded by
-dejagnu, for instance, ~/.dejagnurc:</para>
+<para>In all test cases you can temporary adjust the verbosity of
+information by adding the following Tcl command to any Tcl file that
+gets loaded by dejagnu, for instance, ~/.dejagnurc:</para>
 
 <programlisting>
 set verbose 9
@@ -480,7 +481,7 @@ expect {
 
 <para>Testing remote targets is a lot trickier especially if you are using an
  embedded target
-which has no built in support for things like a compiler, ftp server or a Bash-shell.
+which has no built in support for things like a compiler, FTP server or a Bash-shell.
 Before you can test calc on a remote target you have to acquire a few basics skills.</para>
 
 <sect3>
@@ -488,7 +489,7 @@ Before you can test calc on a remote target you have to acquire a few basics ski
 <para>The easiest remote host is usually the host you are working on.
 In this example we will use telnet to login in your own workstation.
 For security reasons you should never have a telnet daemon running on
-machine connected on the internet, as password and usernames are transmitted
+machine connected on the Internet, as password and user names are transmitted
  in clear text.
 We assume you know how to setup your machine for a telnet daemon.</para>
 
@@ -621,7 +622,7 @@ remote_expect $target 5 {
 
 <para>Now setup a real target.
 In the following example we assume as target a PowerBook running Debian.
-As above add a test user "dgt", install telnet and FTP servers.
+As above add a test user "dgt", install Telnet and FTP servers.
 In order to distinguish it from the host add the line
 <programlisting>PS1='test:>'</programlisting> to /home/dgt/.bash_profile.
 Also add a corresponding entry "powerbook" to /etc/hosts and verify that you
@@ -949,7 +950,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
 	  ``triple'' name as used by <command>configure</command>. This
 	  is the type of machine &dj; and the tools to be tested are built
 	  on. For a normal cross this is the same as the host, but for a
-	  canadian cross, they are separate.</para></listitem>
+	  Canadian cross, they are separate.</para></listitem>
 	</varlistentry>
 
         <varlistentry>
@@ -968,7 +969,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
 	  be run on, which may not be the same as the
 	  <emphasis>build</emphasis> machine. If <option>--build</option>
 	  is also specified, then <option>--host</option> refers to the
-	  machine that the tests wil, be run on, not the machine &dj; is run
+	  machine that the tests will be run on, not the machine &dj; is run
 	  on.</para></listitem>
 	</varlistentry>
 
@@ -1669,7 +1670,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
       target between multiple developers. There are settings for both
       remote targets and remote hosts.  Here's an example of a Master
       Config File (also called the Global config file) for a
-      <emphasis>canadian cross</emphasis>. A canadian cross is when
+      <emphasis>Canadian cross</emphasis>. A Canadian cross is when
       you build and test a cross compiler on a machine other than the
       one it's to be hosted on.</para>
 
@@ -1718,7 +1719,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
     don't support Expect, &dj; can be run on the local build
     machine, and it can connect to the remote host and run all the
     tests for this cross compiler on that host. All the remote OS
-    requires is a working telnetd.</para>
+    requires is a working Telnet server.</para>
 
     <para>As you can see, all one does is set the variable
     <symbol>target_list</symbol> to the list of targets and options to
@@ -1815,11 +1816,11 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
     <sect2 id="releng" xreflabel="Remote Host Testing">
       <title>Remote Host Testing</title>
 
-      <note><para>Thanks to Dj Delorie for the original paper that
+      <note><para>Thanks to DJ Delorie for the original paper that
       this section is based on.</para></note>
 
       <para>&dj; also supports running the tests on a remote
-      host. To set this up, the remote host needs an ftp server, and a
+      host. To set this up, the remote host needs an FTP server, and a
       telnet server. Currently foreign operating systems used as
       remote hosts are VxWorks, VRTX, DOS/Windows 3.1, MacOS and Windows.</para>
 
@@ -1952,7 +1953,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
       <title>Config File Values</title>
 
       <para>&dj; uses a named array in Tcl to hold all the info for
-      each machine. In the case of a canadian cross, this means host
+      each machine. In the case of a Canadian cross, this means host
       information as well as target information. The named array is
       called <symbol>target_info</symbol>, and it has two indices. The
       following fields are part of the array.</para>
@@ -3152,7 +3153,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
 
       <para>&dj; uses a single header file to assist in unit
       testing. As this file also produces its one test state output,
-      it can be run standalone, which is very useful for testing on
+      it can be run stand-alone, which is very useful for testing on
       embedded systems. This header file has a C and C++ API for the
       test states, with simple totals, and standardized
       output. Because the output has been standardized, &dj; can be