aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBen Elliston <bje@gnu.org>2008-04-07 21:52:11 +1000
committerBen Elliston <bje@gnu.org>2008-04-07 21:53:17 +1000
commit50fbdd118dba066e201c73a8b0155381cd65a32d (patch)
tree8692f1d0c8548916d045abec2e1611483158fb61
parent7cd597d12ffd161206a468963fb791ffa833086e (diff)
downloaddejagnu-50fbdd118dba066e201c73a8b0155381cd65a32d.zip
dejagnu-50fbdd118dba066e201c73a8b0155381cd65a32d.tar.gz
dejagnu-50fbdd118dba066e201c73a8b0155381cd65a32d.tar.bz2
* doc/ref.xml, doc/user.xml: Fix typos.
* doc/dejagnu.texi: Regenerate.
-rw-r--r--ChangeLog5
-rw-r--r--doc/dejagnu.texi96
-rw-r--r--doc/ref.xml40
-rw-r--r--doc/user.xml42
4 files changed, 94 insertions, 89 deletions
diff --git a/ChangeLog b/ChangeLog
index 784e6c6..aa1fb71 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-04-07 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
+
+ * doc/ref.xml, doc/user.xml: Fix typos.
+ * doc/dejagnu.texi: Regenerate.
+
2008-04-06 Daniel Jacobowitz <drow@false.org>
* Makefile.am (RUNTESTDEFAULTFLAGS): Add RUNTEST=$(RUNTEST).
diff --git a/doc/dejagnu.texi b/doc/dejagnu.texi
index d2e1fb3..6e80aeb 100644
--- a/doc/dejagnu.texi
+++ b/doc/dejagnu.texi
@@ -486,7 +486,7 @@ dgt:~$ cd ~/dejagnu.test
@end example
Now you are ready to test DejaGnu's main program called
-runtest. The expecteted output is shown
+runtest. The expected output is shown
@strong{Runtest output in a empty directory
}
@@ -538,7 +538,7 @@ http://www.fictional.net/.
If you are running a Debian distribution you can find the
examples under /usr/share/doc/dejagnu/examples. These examples seem to
be missing in Red Hat's RPM. In this case download the sources of
-DejaGnu and adjust the pathes to the DejaGnu examples
+DejaGnu and adjust the paths to the DejaGnu examples
accordingly.
@node Create a minimal project; e_g_ calc, Our first automated tests, Test your installation, Getting DejaGnu up and running
@@ -574,7 +574,7 @@ set objdir /home/dgt/dejagnu.test
@node Using autoconf/autoheader/automake, , A simple project without the GNU autotools, Create a minimal project; e_g_ calc
@subsection Using autoconf/autoheader/automake
-We have to prepare some input file in order to run autocon and
+We have to prepare some input file in order to run autoconf and
automake. There is book "GNU autoconf, automake and
libtool" by Garry V. Vaughan, et al. NewRider, ISBN
1-57870-190-2 which describes this process thoroughly.
@@ -649,7 +649,7 @@ Makefile.am:6: required directory ./doc does not exist
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.
Adapt calc to your environment by calling configure.
@@ -965,14 +965,14 @@ 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 reason you should never have a telnet deamon running on
+For security reasons 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.
Next try whether you may login in your own host by issuing the
command "telnet localhost.1". In order to be able to
-distinguish between a normal session an a telnet login add the following lines to /home/dgt/.bashrc.
+distinguish between a normal session and a telnet login add the following lines to /home/dgt/.bashrc.
@example
@@ -1067,7 +1067,7 @@ In the runtest output you should find something like:
@example
Running ./testsuite/calc.test/local_echo.exp ...
-Running ./testsuite/calc.test/remote_echoo.exp ...
+Running ./testsuite/calc.test/remote_echo.exp ...
this is remote_echo.exp target is unix
Spawn id for remote shell is exp7
@end example
@@ -1248,7 +1248,7 @@ common way is when there is existing support in the
@file{Makefile}. This support consists of a
@emph{check} target. The other way is to execute the
@code{runtest} program directly. To run
-@code{runtest} directcly from the command line requires
+@code{runtest} directly from the command line requires
either all the correct options, or the @ref{Local Config File} must be setup
correctly.
@@ -1276,7 +1276,7 @@ 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
@emph{site.exp}. 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.
@@ -1417,7 +1417,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 seperate.
+canadian cross, they are separate.
@item @code{--host [string]}
@code{string} is a full configuration
@@ -1963,7 +1963,7 @@ subdirectory of the DejaGnu library directory.
targets and hosts supported by DejaGnu. This master file is
identified by setting the environment variable
@code{DEJAGNU} to the name of the file. This is also
-refered to as the ``global'' config file.
+referred to as the ``global'' config file.
Any directory containing a configured testsuite also has a
local @file{site.exp}, capturing configuration values
@@ -2055,7 +2055,7 @@ defined in this config file are related to the configuration of
the test run. This is the ideal place to set the variables
@code{host_triplet}, @code{build_triplet},
@code{target_triplet}. All other variables are tool
-dependant, i.e., for testing a compiler, the value for
+dependent, i.e., for testing a compiler, the value for
@code{CC} might be set to a freshly built binary, as
opposed to one in the user's path.
@@ -2086,7 +2086,7 @@ GCC/G++ testing.
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.
@@ -2105,7 +2105,7 @@ you build and test a cross compiler on a machine other than the
one it's to be hosted on.
Here we have the config settings for our California
-office. Note that all config values are site dependant. Here we
+office. Note that all config values are site dependent. Here we
have two sets of values that we use for testing m68k-aout cross
compilers. As both of these target boards has a different
debugging protocol, we test on both of them in sequence.
@@ -2170,7 +2170,7 @@ this last feature is mostly compiler specific.
@node Board Config File, Remote Host Testing, Global Config File, Customizing DejaGnu
@section Board Config File
-The board config file is where board specfic config data
+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
@@ -2180,10 +2180,10 @@ more information on adding a new board config file, go to the @ref{Adding A New
An example board config file for a GNU simulator is as
follows. @code{set_board_info} is a procedure that sets the
field name to the specified value. The procedures in square brackets
-@emph{[]} are @emph{helper procedures}. Thes
+@emph{[]} are @emph{helper procedures}. 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.
@strong{Board Config File}
@@ -2455,7 +2455,7 @@ host.
The personal config file is used to customize
@code{runtest's} behaviour for each person. It is
-typically used to set the user prefered setting for verbosity,
+typically used to set the user preferred setting for verbosity,
and any experimental Tcl procedures. My personal
@file{~/.dejagnurc} file looks like:
@@ -2810,7 +2810,7 @@ you can include one board file into another, The two main procedures used
to do this are @code{load_generic_config} and
@code{load_base_board_description}. 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.
@@ -3014,7 +3014,7 @@ are usually easier to write.
The GCC tests are a good example of batch oriented tests.
All GCC tests consist primarily of a call to a single common
-procedure, Since all the tests either have no output, or only
+procedure, since all the tests either have no output, or only
have a few warning messages when successfully compiled. Any
non-warning output is a test failure. All the C code needed is
kept in the test directory. The test driver, written in Tcl,
@@ -3314,7 +3314,7 @@ global variables to see if the function or method worked.
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.
@@ -3370,7 +3370,7 @@ source tree, specifying where to find the source with the optional
@emph{autoconf} to configure itself. For more info on using
autoconf, read the GNU autoconf manual. To configure, execute the
@file{configure} program, no other options are
-required. For an example, to configure in a seperate tree for objects,
+required. For an example, to configure in a separate tree for objects,
execute the configure script from the source tree like this:
@example
@@ -3416,7 +3416,7 @@ execute.
@end example
-@emph{make install}does thes things for
+@emph{make install}does these things for
DejaGnu:
@itemize
@@ -3461,7 +3461,7 @@ DejaGnu provides these Tcl procedures.
* Procedures For Using Utilities to Connect: connprocs.
* Procedures For Target Boards::
* Target Database Procedures: target database library file.
-* Platform Dependant Procedures: platform dependant procedures.
+* Platform Dependent Procedures: platform dependent procedures.
* Utility Procedures::
* Libgloss, A Free BSP: Libgloss.
* Procedures for debugging your Tcl code.: Debugging Procedures.
@@ -3581,7 +3581,7 @@ configuration.
@subsubsection is3way Procedure
Tests for a canadian cross. This is when the tests will be run
-on a remotly hosted cross compiler. If it is a canadian cross, then
+on a remotely hosted cross compiler. If it is a canadian cross, then
the result is @emph{1}; otherwise the result is
@emph{0}.
@@ -3741,7 +3741,7 @@ outcomes.
Warning you must clear the expected failure after
using setup_xfail in a test case. Any call to @code{pass
-}or @code{fail}l clears the expected failure
+}or @code{fail} clears the expected failure
implicitly; if the test has some other outcome, e.g. an error, you
can call @code{clear_xfail} to clear the expected
failure explicitly. Otherwise, the expected-failure declaration
@@ -3762,7 +3762,7 @@ The config triplet to trigger whether this is an
unexpected or expect failure.
@item @code{bugid}
-The optional bugid, used to tie it this test case
+The optional bugid, used to tie this test case
to a bug tracking system.
@end table
@@ -3942,7 +3942,7 @@ known side effects.
@item @code{string}
@item @code{number}
-The optional number to set the error counter. Thius
+The optional number to set the error counter. This
is only used to fake out the counter when using the
@code{xfail} procedure to control when it flips the
output over to @emph{UNRESOLVED}
@@ -3979,7 +3979,7 @@ errors with no known side effects.
@item @code{string}
@item @code{number}
-The optional number to set the error counter. Thius
+The optional number to set the error counter. This
is only used to fake out the counter when using the
@code{xfail} procedure to control when it flips the
output over to @emph{UNRESOLVED}
@@ -4195,9 +4195,9 @@ match) then this conditional is de-activated.
What this does is it matches only for these two targets if
"-Wall -v" or "-O3" is set, but neither "-O1" or "-Map" is set. For
-a set to match, the options specified are searched for independantly
+a set to match, the options specified are searched for independently
of each other, so a "-Wall -v" matches either "-Wall -v" or "-v
--Wall". A space seperates the options in the string. Glob-style
+-Wall". A space separates the options in the string. Glob-style
regular expressions are also permitted.
@node clear_xfail procedure, verbose procedure, check_conditional_xfail procedure, Core Internal Procedures
@@ -5071,7 +5071,7 @@ the @code{target_info} array.
@item @code{dest}
-@item @code{commndline}
+@item @code{commandline}
@end table
@node standard_transmit procedure, standard_upload procedure, standard_spawn procedure, Procedures For Remote Communication
@@ -5211,7 +5211,7 @@ port number. The value of the
@code{netport} field in the
@code{target_info} array is used. (was
@code{$netport}) This value has two parts,
-the hostname and the port number, seperated by a
+the hostname and the port number, separated by a
@emph{:}. If host or target is used in
the @code{hostname} field, than the
config array is used for all information.
@@ -5611,7 +5611,7 @@ programs in ASCII S-records. Returns
@item @code{file}
This is the filename to
-downlaod.
+download.
@end table
@node Procedures For Target Boards, target database library file, connprocs, Builtin Procedures
@@ -5806,7 +5806,7 @@ downlaod.
@item @code{options}
@end table
-@node target database library file, platform dependant procedures, Procedures For Target Boards, Builtin Procedures
+@node target database library file, platform dependent procedures, Procedures For Target Boards, Builtin Procedures
@subsection Target Database Procedures
@menu
@@ -6099,8 +6099,8 @@ running the tool to be tested, not a test case.
@item @code{cmdline}
@end table
-@node platform dependant procedures, Utility Procedures, target database library file, Builtin Procedures
-@subsection Platform Dependant Procedures
+@node platform dependent procedures, Utility Procedures, target database library file, Builtin Procedures
+@subsection Platform Dependent Procedures
Each combination of target and tool requires some
target-dependent procedures. The names of these procedures have
@@ -6134,7 +6134,7 @@ and @emph{-1} if there was a communication error.
* $@{tool@}_version Procedure: $@{tool@}_version procedure.
@end menu
-@node $@{tool@}_start procedure, $@{tool@}_load procedure, , platform dependant procedures
+@node $@{tool@}_start procedure, $@{tool@}_load procedure, , platform dependent procedures
@subsubsection $@{tool@}_start Procedure
Starts a particular tool. For an interactive tool,
@@ -6163,7 +6163,7 @@ arrangements to run the tool).
@t{@b{$@{tool@}_start}(@i{});}
@end quotation
-@node $@{tool@}_load procedure, $@{tool@}_exit procedure, $@{tool@}_start procedure, platform dependant procedures
+@node $@{tool@}_load procedure, $@{tool@}_exit procedure, $@{tool@}_start procedure, platform dependent procedures
@subsubsection $@{tool@}_load Procedure
Loads something into a tool. For an interactive tool,
@@ -6188,7 +6188,7 @@ downloading. Test scripts call
@t{@b{$@{tool@}_load}(@i{});}
@end quotation
-@node $@{tool@}_exit procedure, $@{tool@}_version procedure, $@{tool@}_load procedure, platform dependant procedures
+@node $@{tool@}_exit procedure, $@{tool@}_version procedure, $@{tool@}_load procedure, platform dependent procedures
@subsubsection $@{tool@}_exit Procedure
Cleans up (if necessary) before DejaGnu exits. For
@@ -6203,7 +6203,7 @@ tests. @code{runtest} calls
@t{@b{$@{tool@}_exit}(@i{});}
@end quotation
-@node $@{tool@}_version procedure, , $@{tool@}_exit procedure, platform dependant procedures
+@node $@{tool@}_version procedure, , $@{tool@}_exit procedure, platform dependent procedures
@subsubsection $@{tool@}_version Procedure
Prints the version label and number for
@@ -6217,7 +6217,7 @@ tool, and its version number.
@t{@b{$@{tool@}_version}(@i{});}
@end quotation
-@node Utility Procedures, Libgloss, platform dependant procedures, Builtin Procedures
+@node Utility Procedures, Libgloss, platform dependent procedures, Builtin Procedures
@subsection Utility Procedures
@menu
@@ -6261,7 +6261,7 @@ If you do not specify
@emph{*}. You may use the common shell
wildcard characters in the pattern. If no directories
match the pattern, then a NULL string is
-returned
+returned.
@end table
@node find procedure, which procedure, getdirs procedure, Utility Procedures
@@ -6288,7 +6288,7 @@ The top level directory to search the search
from.
@item @code{pattern}
-A csh "glob" style regular expression reprsenting
+A csh "glob" style regular expression representing
the files to find.
@end table
@@ -6296,7 +6296,7 @@ the files to find.
@subsubsection Which Procedure
Searches the execution path for an executable file
-@emph{binary}, like the the BSD @code{which}
+@emph{binary}, like the BSD @code{which}
utility. This procedure uses the shell environment variable
@emph{PATH}. It returns @emph{0} if the
binary is not in the path, or if there is no @emph{PATH}
@@ -7031,7 +7031,7 @@ The variable to watch.
@node watchdel procedure, print procedure, watchread procedure, Debugging Procedures
@subsubsection Watchdel Procedure
-This deletes a the watchpoint from the watch list. It is
+This deletes a watchpoint from the watch list. It is
abbreviated as @emph{wd}.
@quotation
@@ -7173,7 +7173,7 @@ lib/dejagnu.exp
All of the functions that take a
@code{msg} 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.
@menu
@@ -7246,7 +7246,7 @@ state outputs.
All of the methods that take a
@code{msg} 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.
@menu
diff --git a/doc/ref.xml b/doc/ref.xml
index 988fe35..3257881 100644
--- a/doc/ref.xml
+++ b/doc/ref.xml
@@ -30,7 +30,7 @@
<emphasis>autoconf</emphasis> to configure itself. For more info on using
autoconf, read the GNU autoconf manual. To configure, execute the
<filename>configure</filename> program, no other options are
- required. For an example, to configure in a seperate tree for objects,
+ required. For an example, to configure in a separate tree for objects,
execute the configure script from the source tree like this:</para>
<screen>
@@ -74,7 +74,7 @@
eg$ make install
</screen>
- <para><emphasis>make install</emphasis>does thes things for
+ <para><emphasis>make install</emphasis>does these things for
&dj;:</para>
<itemizedlist mark="bullet">
@@ -205,7 +205,7 @@
<title>is3way Procedure</title>
<para>Tests for a canadian cross. This is when the tests will be run
- on a remotly hosted cross compiler. If it is a canadian cross, then
+ 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>
@@ -402,7 +402,7 @@
<warning><para>Warning you must clear the expected failure after
using setup_xfail in a test case. Any call to <function>pass
- </function>or <function>fail</function>l clears the expected failure
+ </function>or <function>fail</function> clears the expected failure
implicitly; if the test has some other outcome, e.g. an error, you
can call <function>clear_xfail</function> to clear the expected
failure explicitly. Otherwise, the expected-failure declaration
@@ -424,7 +424,7 @@
</varlistentry>
<varlistentry>
<term><parameter>bugid</parameter></term>
- <listitem><para>The optional bugid, used to tie it this test case
+ <listitem><para>The optional bugid, used to tie this test case
to a bug tracking system.</para></listitem>
</varlistentry>
</variablelist>
@@ -636,7 +636,7 @@
</varlistentry>
<varlistentry>
<term><parameter>number</parameter></term>
- <listitem><para>The optional number to set the error counter. Thius
+ <listitem><para>The optional number to set the error counter. This
is only used to fake out the counter when using the
<function>xfail</function> procedure to control when it flips the
output over to <emphasis>UNRESOLVED</emphasis>
@@ -678,7 +678,7 @@
</varlistentry>
<varlistentry>
<term><parameter>number</parameter></term>
- <listitem><para>The optional number to set the error counter. Thius
+ <listitem><para>The optional number to set the error counter. This
is only used to fake out the counter when using the
<function>xfail</function> procedure to control when it flips the
output over to <emphasis>UNRESOLVED</emphasis>
@@ -922,9 +922,9 @@
<para>What this does is it matches only for these two targets if
"-Wall -v" or "-O3" is set, but neither "-O1" or "-Map" is set. For
- a set to match, the options specified are searched for independantly
+ a set to match, the options specified are searched for independently
of each other, so a "-Wall -v" matches either "-Wall -v" or "-v
- -Wall". A space seperates the options in the string. Glob-style
+ -Wall". A space separates the options in the string. Glob-style
regular expressions are also permitted.</para>
</sect4>
@@ -2055,7 +2055,7 @@
<listitem><para></para></listitem>
</varlistentry>
<varlistentry>
- <term><parameter>commndline</parameter></term>
+ <term><parameter>commandline</parameter></term>
<listitem><para></para></listitem>
</varlistentry>
</variablelist>
@@ -2236,7 +2236,7 @@
<parameter>netport</parameter> field in the
<symbol>target_info</symbol> array is used. (was
<symbol>$netport</symbol>) This value has two parts,
- the hostname and the port number, seperated by a
+ the hostname and the port number, separated by a
<emphasis>:</emphasis>. If host or target is used in
the <symbol>hostname</symbol> field, than the
config array is used for all information.</para></listitem>
@@ -2781,7 +2781,7 @@
<varlistentry>
<term><parameter>file</parameter></term>
<listitem><para>This is the filename to
- downlaod.</para></listitem>
+ download.</para></listitem>
</varlistentry>
</variablelist>
</sect4>
@@ -3403,8 +3403,8 @@
</sect4>
</sect3>
- <sect3 id="platformprocs" xreflabel="platform dependant procedures">
- <title>Platform Dependant Procedures</title>
+ <sect3 id="platformprocs" xreflabel="platform dependent procedures">
+ <title>Platform Dependent Procedures</title>
<para>Each combination of target and tool requires some
target-dependent procedures. The names of these procedures have
@@ -3558,7 +3558,7 @@
<emphasis>*</emphasis>. You may use the common shell
wildcard characters in the pattern. If no directories
match the pattern, then a NULL string is
- returned</para></listitem>
+ returned.</para></listitem>
</varlistentry>
</variablelist>
</sect4>
@@ -3589,7 +3589,7 @@
</varlistentry>
<varlistentry>
<term><parameter>pattern</parameter></term>
- <listitem><para>A csh "glob" style regular expression reprsenting
+ <listitem><para>A csh "glob" style regular expression representing
the files to find.</para></listitem>
</varlistentry>
</variablelist>
@@ -3599,7 +3599,7 @@
<title>Which Procedure</title>
<para>Searches the execution path for an executable file
- <emphasis>binary</emphasis>, like the the BSD <command>which</command>
+ <emphasis>binary</emphasis>, like the BSD <command>which</command>
utility. This procedure uses the shell environment variable
<emphasis>PATH</emphasis>. It returns <emphasis>0</emphasis> if the
binary is not in the path, or if there is no <emphasis>PATH</emphasis>
@@ -4470,7 +4470,7 @@
<sect4 id="watchdel" xreflabel="watchdel procedure">
<title>Watchdel Procedure</title>
- <para>This deletes a the watchpoint from the watch list. It is
+ <para>This deletes a watchpoint from the watch list. It is
abbreviated as <emphasis>wd</emphasis>.</para>
<funcsynopsis role="tcl">
@@ -4577,7 +4577,7 @@
<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>
@@ -4663,7 +4663,7 @@
<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>
<sect3 id="passmeth" xreflabel="pass method">
diff --git a/doc/user.xml b/doc/user.xml
index 2186d5c..b79adac 100644
--- a/doc/user.xml
+++ b/doc/user.xml
@@ -36,7 +36,7 @@ dgt:~$ cd ~/dejagnu.test
</programlisting>
<para>Now you are ready to test &dj;'s main program called
-runtest. The expecteted output is shown</para>
+runtest. The expected output is shown</para>
<example>
<title>Runtest output in a empty directory
@@ -83,7 +83,7 @@ http://www.fictional.net/.</para>
<para>If you are running a Debian distribution you can find the
examples under /usr/share/doc/dejagnu/examples. These examples seem to
be missing in Red Hat's RPM. In this case download the sources of
-&dj; and adjust the pathes to the &dj; examples
+&dj; and adjust the paths to the &dj; examples
accordingly.</para>
</sect3>
</sect2>
@@ -113,7 +113,7 @@ set objdir /home/dgt/dejagnu.test
<sect3>
<title>Using autoconf/autoheader/automake</title>
-<para>We have to prepare some input file in order to run autocon and
+<para>We have to prepare some input file in order to run autoconf and
automake. There is book &quot;GNU autoconf, automake and
libtool&quot; by Garry V. Vaughan, et al. NewRider, ISBN
1-57870-190-2 which describes this process thoroughly.</para>
@@ -184,7 +184,7 @@ Makefile.am:6: required directory ./doc does not exist
<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>
@@ -484,14 +484,14 @@ Before you can test calc on a remote target you have to acquire a few basics ski
<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 reasons 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
command &quot;telnet localhost.1&quot;. In order to be able to
-distinguish between a normal session an a telnet login add the following lines to /home/dgt/.bashrc.</para>
+distinguish between a normal session and a telnet login add the following lines to /home/dgt/.bashrc.</para>
<programlisting>
if [ "$REMOTEHOST" ]
@@ -583,7 +583,7 @@ if { $shell_id > 0 } {
<programlisting>
Running ./testsuite/calc.test/local_echo.exp ...
-Running ./testsuite/calc.test/remote_echoo.exp ...
+Running ./testsuite/calc.test/remote_echo.exp ...
this is remote_echo.exp target is unix
Spawn id for remote shell is exp7
</programlisting>
@@ -767,7 +767,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<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>
@@ -787,7 +787,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
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 &dj; used to dertermine the
+ various variables that &dj; used to determine the
configuration of the program being tested. This is mostly for
supporting remote testing.</para>
@@ -946,7 +946,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 seperate.</para></listitem>
+ canadian cross, they are separate.</para></listitem>
</varlistentry>
<varlistentry>
@@ -1536,7 +1536,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
targets and hosts supported by &dj;. 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
@@ -1620,7 +1620,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
the test run. This is the ideal place to set the variables
<symbol>host_triplet</symbol>, <symbol>build_triplet</symbol>,
<symbol>target_triplet</symbol>. All other variables are tool
- dependant, i.e., for testing a compiler, the value for
+ dependent, i.e., for testing a compiler, the value for
<symbol>CC</symbol> might be set to a freshly built binary, as
opposed to one in the user's path.</para>
@@ -1651,7 +1651,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<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 &dj; itself for cross testing, but to test a
compiler, GCC needs to manipulate these itself.</para>
@@ -1671,7 +1671,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
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
+ office. Note that all config values are site dependent. Here we
have two sets of values that we use for testing m68k-aout cross
compilers. As both of these target boards has a different
debugging protocol, we test on both of them in sequence.</para>
@@ -1738,7 +1738,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<sect2 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
@@ -1749,10 +1749,10 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<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>
@@ -2086,7 +2086,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<para>The personal config file is used to customize
<command>runtest's</command> behaviour for each person. It is
- typically used to set the user prefered setting for verbosity,
+ typically used to set the user preferred setting for verbosity,
and any experimental Tcl procedures. My personal
<filename>~/.dejagnurc</filename> file looks like:</para>
@@ -2435,7 +2435,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
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>
@@ -2843,7 +2843,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<para>The GCC tests are a good example of batch oriented tests.
All GCC tests consist primarily of a call to a single common
- procedure, Since all the tests either have no output, or only
+ procedure, since all the tests either have no output, or only
have a few warning messages when successfully compiled. Any
non-warning output is a test failure. All the C code needed is
kept in the test directory. The test driver, written in Tcl,
@@ -3138,7 +3138,7 @@ powerpc-linux-gcc -g -O2 -o calc calc.o
<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>