possibly introduced in a conversion of .texi to SGML Docbook.
* doc/user.xml: Likewise.
* doc/ref.xml: Likewise.
* doc/dejagnu.texi: Regenerate.
Signed-off-by: Ben Elliston <bje@gnu.org>
2015-05-15 Filipe Brandenburger <filbranden@google.com>
+ * doc/dejagnu.xml: Fix typos such as stray }'s and @samp{...},
+ possibly introduced in a conversion of .texi to SGML Docbook.
+ * doc/user.xml: Likewise.
+ * doc/ref.xml: Likewise.
+ * doc/dejagnu.texi: Regenerate.
+
+2015-05-15 Filipe Brandenburger <filbranden@google.com>
+
* runtest.exp (runtest): Introduce new --log_dialog option.
* doc/runtest.1: Document it.
* doc/user.xml: Likewise.
DejaGnu uses the same output procedures to produce these messages
for all testsuites and these procedures are already known to conform
to POSIX 1003.3. For a DejaGnu testsuite to conform to POSIX 1003.3,
-you must avoid the @emph{setup}xfail@} procedure as
+you must avoid the @emph{setup_xfail} procedure as
described in the @emph{PASS} section above and you must
be careful to return @emph{UNRESOLVED} where appropriate,
as described in the @emph{UNRESOLVED} section
affects @emph{only} DejaGnu procedures that compare the
host string with particular values. The procedures
@emph{ishost}, @emph{istarget},
-@emph{isnative}, and @emph{setup}xfail@}
+@emph{isnative}, and @emph{setup_xfail}
are affected by @code{--host}. In this usage,
@emph{host} refers to the machine that the tests are to
be run on, which may not be the same as the
@file{dbg.log}. The extra debugging output does
@emph{not} appear on standard output, unless the
verbose level is greater than 2 (for instance, to see debug output
-immediately, specify @code{--debug}-v -v@}). The
+immediately, specify @code{--debug -v -v}). The
debugging output shows all attempts at matching the test output of
the tool with the scripted patterns describing expected output. The
output generated with @code{--strace} also goes into
@item @code{--outdir [path]}
Write output logs in directory
-@file{path}. The default is @emph{.@},
-the} directory where you start
-@emph{runtest}. This option affects only the summary
-and the detailed log files
+@file{path}. The default is @emph{.},
+the directory where you start @emph{runtest}. This
+option affects only the summary and the detailed log files
@file{tool.sum} and
@file{tool.log}. The DejaGnu debug
log @file{dbg.log} always appears (when requested) in
for test scripts to run. @emph{runtest} looks in this
directory for any subdirectory whose name begins with the toolname
(specified with @code{--tool}). For instance, with
-@code{--tool}gdb@}, @emph{runtest} uses
+@code{--tool gdb}, @emph{runtest} uses
tests in subdirectories @file{gdb.*} (with the usual
shell-like filename expansion). If you do not use
@code{--srcdir}, @emph{runtest} looks for
@item @code{--verbose} (-v)
Turns on more output. Repeating this option increases
the amount of output displayed. Level one (@emph{-v})
-is simply test output. Level two (@emph{-v}-v@}) shows
+is simply test output. Level two (@emph{-v -v}) shows
messages on options, configuration, and process control. Verbose
messages appear in the detailed (@file{*.log}) log
file, but not in the summary (@file{*.sum}) log
Usually the best way to write a new initialization module is to
edit an existing initialization module; some trial and error will be
-required. If necessary, you can use the @@samp@{--debug@} option to see what
+required. If necessary, you can use the @code{--debug} option to see what
is really going on.
When you code an initialization module, be generous in printing
@item $prms_id
The tracking system (e.g. GNATS) number identifying
-a corresponding bugreport. (@emph{0}@} if you do not
+a corresponding bugreport. (@emph{0} if you do not
specify it in the test script.)
@item $item bug_id
supporting code installed. By default, installation is in subdirectories
of @file{/usr/local}, but you can select any alternate
directory @code{altdir} by including
-@code{--prefix}@{altdir@}@} on the
+@code{--prefix altdir} on the
@code{configure} command line. (This value is captured in
the Makefile variables @emph{prefix} and
-@emph{exec}prefix@}.)
+@emph{exec_prefix}.)
Save for a small number of example tests, the DejaGnu distribution
itself does not include any testsuites; these are available
arguments.
The other two procedures, @code{$@{tool@}_start}
-and @code{$@{tool@}_load}@}, are only called by the test
+and @code{$@{tool@}_load}, are only called by the test
suites themselves (or by testsuite-specific initialization
code); they may take arguments or not, depending on the
conventions used within each testsuite.
<para>&dj; uses the same output procedures to produce these messages
for all testsuites and these procedures are already known to conform
to POSIX 1003.3. For a &dj; testsuite to conform to POSIX 1003.3,
- you must avoid the <emphasis>setup</emphasis>xfail} procedure as
+ you must avoid the <emphasis>setup_xfail</emphasis> procedure as
described in the <emphasis>PASS</emphasis> section above and you must
be careful to return <emphasis>UNRESOLVED</emphasis> where appropriate,
as described in the <emphasis>UNRESOLVED</emphasis> section
supporting code installed. By default, installation is in subdirectories
of <filename>/usr/local</filename>, but you can select any alternate
directory <symbol>altdir</symbol> by including
- <option>--prefix</option>{altdir}} on the
+ <option>--prefix altdir</option> on the
<command>configure</command> command line. (This value is captured in
the Makefile variables <emphasis>prefix</emphasis> and
- <emphasis>exec</emphasis>prefix}.)</para>
+ <emphasis>exec_prefix</emphasis>.)</para>
<para>Save for a small number of example tests, the &dj; distribution
itself does not include any testsuites; these are available
arguments.</para>
<para>The other two procedures, <symbol>${tool}_start</symbol>
- and <symbol>${tool}_load</symbol>}, are only called by the test
+ and <symbol>${tool}_load</symbol>, are only called by the test
suites themselves (or by testsuite-specific initialization
code); they may take arguments or not, depending on the
conventions used within each testsuite.</para>
affects <emphasis>only</emphasis> &dj; procedures that compare the
host string with particular values. The procedures
<emphasis>ishost</emphasis>, <emphasis>istarget</emphasis>,
- <emphasis>isnative</emphasis>, and <emphasis>setup</emphasis>xfail}
+ <emphasis>isnative</emphasis>, and <emphasis>setup_xfail</emphasis>
are affected by <option>--host</option>. 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
<filename>dbg.log</filename>. The extra debugging output does
<emphasis>not</emphasis> appear on standard output, unless the
verbose level is greater than 2 (for instance, to see debug output
- immediately, specify <option>--debug</option>-v -v}). The
+ immediately, specify <option>--debug -v -v</option>). The
debugging output shows all attempts at matching the test output of
the tool with the scripted patterns describing expected output. The
output generated with <option>--strace</option> also goes into
<varlistentry>
<term><option>--outdir [path]</option></term>
<listitem><para>Write output logs in directory
- <filename>path</filename>. The default is <emphasis>.},
- the</emphasis> directory where you start
- <emphasis>runtest</emphasis>. This option affects only the summary
- and the detailed log files
+ <filename>path</filename>. The default is <emphasis>.</emphasis>,
+ the directory where you start <emphasis>runtest</emphasis>. This
+ option affects only the summary and the detailed log files
<filename>tool.sum</filename> and
<filename>tool.log</filename>. The &dj; debug
log <filename>dbg.log</filename> always appears (when requested) in
for test scripts to run. <emphasis>runtest</emphasis> looks in this
directory for any subdirectory whose name begins with the toolname
(specified with <option>--tool</option>). For instance, with
- <option>--tool</option>gdb}, <emphasis>runtest</emphasis> uses
+ <option>--tool gdb</option>, <emphasis>runtest</emphasis> uses
tests in subdirectories <filename>gdb.*</filename> (with the usual
shell-like filename expansion). If you do not use
<option>--srcdir</option>, <emphasis>runtest</emphasis> looks for
<term><option>--verbose</option> (-v)</term>
<listitem><para>Turns on more output. Repeating this option increases
the amount of output displayed. Level one (<emphasis>-v</emphasis>)
- is simply test output. Level two (<emphasis>-v</emphasis>-v}) shows
+ is simply test output. Level two (<emphasis>-v -v</emphasis>) shows
messages on options, configuration, and process control. Verbose
messages appear in the detailed (<filename>*.log</filename>) log
file, but not in the summary (<filename>*.sum</filename>) log
<para>Usually the best way to write a new initialization module is to
edit an existing initialization module; some trial and error will be
- required. If necessary, you can use the @samp{--debug} option to see what
+ required. If necessary, you can use the <option>--debug</option> option to see what
is really going on.</para>
<para>When you code an initialization module, be generous in printing
<varlistentry>
<term>$prms_id</term>
<listitem><para>The tracking system (e.g. GNATS) number identifying
- a corresponding bugreport. (<emphasis>0</emphasis>} if you do not
+ a corresponding bugreport. (<emphasis>0</emphasis> if you do not
specify it in the test script.)</para></listitem>
</varlistentry>