[Bug-dejagnu] Patches for typos in SGML doc

[Benoît SIBAUD]

Hi,

two patches to fix misspelled words in doc/ref.sgml and doc/user.sgml
(aspell -c -H -d english XXX.sgml)

Regards,

--
Benoît Sibaud

--- ref.sgml.old        2004-02-27 16:48:24.000000000 +0100
+++ ref.sgml    2004-02-27 17:04:27.000000000 +0100
@@ -71,11 +71,11 @@
 
       <screen>
         eg$ make install
       </screen>
 
-      <para><emphasis>make install</emphasis>does thes things for
+      <para><emphasis>make install</emphasis> does these things for
       DejaGnu:</para>
 
       <itemizedlist mark=bullet>
         <listitem><para>Look in the path specified for executables
           <symbol>$exec_prefix</symbol>) for directories called
@@ -4270,11 +4270,11 @@
     <sect1 id=cunit xreflabel="C Unit Testing API">
     <title>C Unit Testing API</title>
 
     <para>All of the functions that take a
     <parameter>msg</parameter> parameter use a C char * that is
-    the message to be dislayed. There currently is no support for
+    the message to be displayed. There currently is no support for
     variable length arguments.</para>
 
 
     <sect2 id=passfunc xreflabel="pass function">
     <title>Pass Function</title>
@@ -4346,11 +4346,11 @@
           <title>C++ Unit Testing API</title>
 
           <para>All of the methods that take a
                  <parameter>msg</parameter> parameter use a C char *
                  or STL string, that is the message to be
-                 dislayed. There currently is no support for variable
+                 displayed. There currently is no support for variable
                  length arguments.</para>
 
           <sect2 id=passmeth xreflabel="pass method">
           <title>Pass Method</title>
 

--- user.sgml.old       2004-02-27 16:07:49.000000000 +0100
+++ user.sgml   2004-02-27 17:02:53.000000000 +0100
@@ -1,11 +1,11 @@
   <chapter id=gettingup>
     <title>Getting DejaGnu up and running</title>
 <para>This chapter was originally written by Niklaus Giger (address@hidden) 
because he lost a week to figure out how DejaGnu works and how to write a first 
test.</para>
 
 <para>Follow these instructions as closely a possible in order get a good 
insight into how DejaGnu works, else you might run into a lot of subtle 
problems. You have been warned.</para>
-<para>It should be no big problems installing DejaGnu using your package 
manager or from the source code. Under a Debian/GNU/Linux systems just type (as 
root) <programlisting>apt-get dejagnu</programlisting>. These examples were run 
on a primary machine with a AMD K6 and a Mac Powerbook G3 serving as a remote 
target.</para>
+<para>It should be no big problems installing DejaGnu using your package 
manager or from the source code. Under a Debian GNU/Linux systems just type (as 
root) <programlisting>apt-get dejagnu</programlisting>. These examples were run 
on a primary machine with a AMD K6 and a Mac Powerbook G3 serving as a remote 
target.</para>
 
 <para> The tests for Windows were run under Windows NT using the actual Cygwin 
version (1.3.x as of October 2001). It's target system was a PPC embedded 
system running vxWorks.
 </para>
 
 <sect1>
@@ -16,11 +16,11 @@
 <programlisting>
 dgt:~$ mkdir ~/dejagnu.test
 dgt:~$ cd ~/dejagnu.test
 </programlisting>
 
-<para>Now you are ready to test DejaGnu's main program called runtest. The 
expecteted output is shown</para>
+<para>Now you are ready to test DejaGnu's main program called runtest. The 
expected output is shown</para>
 
 <example>
 <title>Runtest output in a empty directory
 </title>
 
@@ -77,20 +77,20 @@
 </programlisting></sect2>
 
 <sect2>
 <title>Using autoconf/autoheader/automake</title>
 
-<para>We have to prepare some input file in order to run autocon and automake. 
There is book &ldquo;GNU autoconf, automake and libtool&rdquo; by Garry V. 
Vaughan, et al. NewRider, ISBN 1-57870-190-2 which describes this process 
thoroughly.</para>
+<para>We have to prepare some input file in order to run autoconf and 
automake. There is book &ldquo;GNU autoconf, automake and libtool&rdquo; by 
Garry V. Vaughan, et al. NewRider, ISBN 1-57870-190-2 which describes this 
process thoroughly.</para>
 
 <para>From the calc example distributed with the DejaGnu documentation you 
should copy the program file itself (calc.c) and some additional files, which 
you might examine a little bit close to derive their meanings.</para>
 
 <programlisting>
 dgt:~/dejagnu.test$ cp -r /usr/share/doc/dejagnu/examples/calc/\
 {configure.in,Makefile.am,calc.c,testsuite} .
 </programlisting>
 
-<para>In Makemake.am note the presence of the AUTOMAKE_OPTIONS = dejagnu. This 
option is needed.</para>
+<para>In Makefile.am note the presence of the AUTOMAKE_OPTIONS = dejagnu. This 
option is needed.</para>
 
 <para>Run aclocal to generate aclocal.m4, which is a collection of macros 
needed by configure.in</para>
 
 <programlisting>
 dgt:~/dejagnu.test$ aclocal
@@ -140,11 +140,11 @@
 </example>
 
 <para>Create a empty directory doc and empty files
 INSTALL, NEWS, README, AUTHORS, ChangeLog and COPYING.
 The default COPYING will point to the GNU Public License (GPL).
-In a real project it would be time to add some meaningfull text in each file.
+In a real project it would be time to add some meaningful text in each file.
 </para>
 
 <para>Adapt calc to your environment by calling configure.</para>
 <example>
 <title>Sample output of configure
@@ -431,11 +431,11 @@
 
 <sect2>
 <title>Setup telnet to your own host</title>
 <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 reason you should never have a telnet deamon running on
+For security reason you should never have a telnet daemon running on
 machine connected on the internet, as password and usernames are transmitted
  in clear text.
 We assume you know how to setup your machine for a telnet daemon.</para>
 
 <para>Next try whether you may login in your own host by issuing the
@@ -559,11 +559,11 @@
 }
 </programlisting>
 </example>
 
 <para>Call make check. The output should contain
-&ldquo;&num; of expected passes 9&rdquo; and &ldquo;&num; of unexcpected 
failures 1&rdquo;.</para>
+&ldquo;&num; of expected passes 9&rdquo; and &ldquo;&num; of unexpected 
failures 1&rdquo;.</para>
 
 <para>Have a look at the procedures in /usr/share/dejagnu/remote.exp to have 
an overview of the offered procedures and their features. </para>
 
 <para>Now setup a real target.
 In the following example we assume as target a PowerBook running Debian.
@@ -608,11 +608,11 @@
      fail "Remote download to $remfile on $target"
 } else {
    pass "$test"
 }
 
-puts "status of remote_download ist $status"
+puts "status of remote_download is $status"
 # set verbose 0
 </programlisting>
 </example>
 
 <para>After running runtest again, check whether the file dejagnu2 exists on 
the target.
@@ -714,11 +714,11 @@
     <para>There are two ways to execute a testsuite. The most
     common way is when there is existing support in the
     <filename>Makefile</filename>. This support consists of a
     <emphasis>check</emphasis> target. The other way is to execute the
     <command>runtest</command> program directly. To run
-    <command>runtest</command> directcly from the command line requires
+    <command>runtest</command> directly from the command line requires
     either all the correct options, or the <xref linkend=local> must be setup
     correctly.</para>
 
     <sect1 id=makecheck xreflabel="Make Check">
       <title>Make check</title>
@@ -734,11 +734,11 @@
       <para>If the <emphasis>check</emphasis> target exists, it
       usually saves you some trouble. For instance, it can set up any
       auxiliary programs or other files needed by the tests. The most
       common file the check builds is the
       <emphasis>site.exp</emphasis>. The site.exp file contains
-      various variables that DejaGnu used to dertermine the
+      various variables that DejaGnu used to determine the
       configuration of the program being tested. This is mostly for
       supporting remote testing.</para>
 
       <para>The <emphasis>check</emphasis> target is supported by GNU
       <productname>Automake</productname>. To have DejaGnu support added to 
your
@@ -795,11 +795,11 @@
 
        <varlistentry>
          <term>FAIL</term>
           <listitem><para>A test failed, although it was expected to succeed.
           This may indicate regress; inspect the test case and the failing
-          software to ocate the bug.</para></listitem>
+          software to locate the bug.</para></listitem>
        </varlistentry>
 
        <varlistentry>
          <term>XFAIL</term>
           <listitem><para>A test failed, but it was expected to fail.  This
@@ -893,11 +893,11 @@
           <term><option>--build [string]</option></term>
          <listitem><para><emphasis>string</emphasis> is a full configuration
          ``triple'' name as used by <command>configure</command>. 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 seperate.</para></listitem>
+         Canadian cross, they are separate.</para></listitem>
        </varlistentry>
 
         <varlistentry>
           <term><option>--host [string]</option></term>
          <listitem><para><symbol>string</symbol> is a full configuration
@@ -912,11 +912,11 @@
          are affected by <emphasis>--host</emphasis>. In this usage,
          <emphasis>host</emphasis> refers to the machine that the tests are to
          be run on, which may not be the same as the
          <emphasis>build</emphasis> machine. If <emphasis>--build</emphasis>
          is also specified, then <emphasis>--host</emphasis> 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.</para></listitem>
        </varlistentry>
 
         <varlistentry>
           <term><option>--host_board [name]</option></term>
@@ -1244,11 +1244,11 @@
       regardless of whether or not you specify
       <option>--all</option>.)</para>
 
       <para>If any of your tests use the procedures
       <command>unresolved</command>, <command>unsupported</command>,
-      or <command>runtested</command>, the summary output also
+      or <command>untested</command>, the summary output also
       tabulates the corresponding outcomes.</para>
 
       <para>For example, after <command>runtest --tool
       binutils</command>, look for a summary log in
       <filename>binutils.sum</filename>. Normally, DejaGnu writes this
@@ -1484,11 +1484,11 @@
     <command>runtest</command> loads these values first. The master
     <filename>site.exp</filename> contains the default values for all
     targets and hosts supported by DejaGnu. This master file is
     identified by setting the environment variable
     <symbol>DEJAGNU</symbol> to the name of the file. This is also
-    refered to as the ``global'' config file.</para>
+    referred to as the ``global'' config file.</para>
 
     <para>Any directory containing a configured testsuite also has a
     local <filename>site.exp</filename>, capturing configuration values
     specific to the tool under test.  Since <command>runtest</command>
     loads these values last, the individual test configuration can
@@ -1599,11 +1599,11 @@
       </programlisting>
     </example>
 
     <para>This file defines the required fields for a local config
     file, namely the three config triplets, and the srcdir. It also
-    defines several other Tcl variables that are used exclusivly by
+    defines several other Tcl variables that are used exclusively by
     the GCC testsuite. For most test cases, the CXXFLAGS and LDFLAGS
     are supplied by DejaGnu itself for cross testing, but to test a
     compiler, GCC needs to manipulate these itself.</para>
 
     </sect1>
@@ -1614,11 +1614,11 @@
       config variables for a whole site get set. The idea is
       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
-      <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>
 
       <para>Here we have the config settings for our California
       office. Note that all config values are site dependant. Here we
@@ -1686,25 +1686,25 @@
     </sect1>
 
     <sect1 id=boardconfig xreflabel="Board Config File">
       <title>Board Config File</title>
 
-      <para>The board config file is where board specfic config data
+      <para>The board config file is where board specific config data
       is stored. A board config file contains all the higher-level
       configuration settings. There is a rough inheritance scheme, where it is
       possible to base a new board description file on an existing one. There
       are also collections of custom procedures for common environments. For
       more information on adding a new board config file, go to the <xref
       linkend=addboard> chapter. </para>
 
       <para>An example board config file for a GNU simulator is as
       follows. <function>set_board_info</function> is a procedure that sets the
       field name to the specified value. The procedures in square brackets
-      <emphasis>[]</emphasis> are <emphasis>helper procedures</emphasis>. Thes
+      <emphasis>[]</emphasis> are <emphasis>helper procedures</emphasis>. These
       are used to find parts of a tool chain required to build an executable
       image that may reside in various locations. This is mostly of use for
-      when the startup code, the standard C lobraries, or the tool chain itself
+      when the startup code, the standard C libraries, or the tool chain itself
       is part of your build tree.</para>
 
       <example>
         <title>Board Config File</title>
 
@@ -2383,11 +2383,11 @@
       <para>There is a crude inheritance scheme going on with board files, so
       you can include one board file into another, The two main procedures used
       to do this are <function>load_generic_config</function> and
       <function>load_base_board_description</function>. The generic config file
       contains other procedures used for a certain class of target. The
-      board description file is where the board specfic settings go. Commonly
+      board description file is where the board specific settings go. Commonly
       there are similar target environments with just different
       processors.</para>
 
       <example>
       <title>Testing a New Board Config File</title>
@@ -3086,11 +3086,11 @@
       series, with the test case having to check private data or
       global variables to see if the function or method worked.</para>
 
       <para>This works particularly well for testing APIs and at level
       where it is easier to debug them, than by needing to trace through
-      the entire appication. Also if there is a specification for the
+      the entire application. Also if there is a specification for the
       API to be tested, the testcase can also function as a compliance
       test.</para>
 
     </sect1>