Merge branch 'lukas/common_test/rename_run_test/OTP-8936' into dev

* lukas/common_test/rename_run_test/OTP-8936:
  Update ct_run deprectaion warning to work properly on windows
  Update documentation after rename of run_test to ct_run
  Update make and install files to use ct_run instead of run_test and to keep a link to run_test available
  Add deprication warning to run_test.c

11 files changed, 191 insertions, 82 deletions

diff --git a/lib/common_test/doc/src/Makefile b/lib/common_test/doc/src/Makefile
index 6322860088..1a767a8197 100644
--- a/lib/common_test/doc/src/Makefile
+++ b/lib/common_test/doc/src/Makefile
@@ -51,7 +51,7 @@ CT_MODULES = \
 CT_XML_FILES = $(CT_MODULES:=.xml)
 
 XML_APPLICATION_FILES = ref_man.xml
-XML_REF1_FILES = run_test.xml
+XML_REF1_FILES = ct_run.xml
 XML_REF3_FILES = $(CT_XML_FILES)
 XML_REF6_FILES = common_test_app.xml
 
diff --git a/lib/common_test/doc/src/config_file_chapter.xml b/lib/common_test/doc/src/config_file_chapter.xml
index 77b0c0c0b7..59151a73ec 100644
--- a/lib/common_test/doc/src/config_file_chapter.xml
+++ b/lib/common_test/doc/src/config_file_chapter.xml
@@ -248,7 +248,7 @@
 
       <p><c>Callback:check_parameter/1</c></p>
       <p>The input argument will be passed from Common Test, as defined in the test
-	specification or given as an option to <c>run_test</c>.</p>
+	specification or given as an option to <c>ct_run</c> or <c>ct:run_test</c>.</p>
 
       <p>The return value should be any of the following values indicating if given
 	configuration parameter is valid:</p>
diff --git a/lib/common_test/doc/src/cover_chapter.xml b/lib/common_test/doc/src/cover_chapter.xml
index 6e4f59ef73..377409ed7b 100644
--- a/lib/common_test/doc/src/cover_chapter.xml
+++ b/lib/common_test/doc/src/cover_chapter.xml
@@ -94,10 +94,10 @@
 
     <p>To activate the code coverage support, you simply specify the
       name of the cover specification file as you start Common Test.
-      This you do either by using the <c>-cover</c> flag with <c>run_test</c>.
+      This you do either by using the <c>-cover</c> flag with <c>ct_run</c>.
       Example:</p>
 
-    <p><c>$ run_test -dir $TESTOBJS/db -cover $TESTOBJS/db/config/db.coverspec</c></p>
+    <p><c>$ ct_run -dir $TESTOBJS/db -cover $TESTOBJS/db/config/db.coverspec</c></p>
     
     <p>You may also pass the cover specification file name in a
       call to <c>ct:run_test/1</c>, by adding a <c>{cover,CoverSpec}</c>
diff --git a/lib/common_test/doc/src/ct_junit_report.xml b/lib/common_test/doc/src/ct_junit_report.xml
new file mode 100644
index 0000000000..49a40cc1de
--- /dev/null
+++ b/lib/common_test/doc/src/ct_junit_report.xml
@@ -0,0 +1,109 @@
+<?xml version="1.0" encoding="latin1" ?>
+<!DOCTYPE erlref SYSTEM "erlref.dtd">
+<erlref>
+<header>
+<title>ct_junit_report</title>
+<prepared></prepared>
+<responsible></responsible>
+<docno>1</docno>
+<approved></approved>
+<checked></checked>
+<date></date>
+<rev>A</rev>
+<file>ct_junit_report.xml</file></header>
+<module>ct_junit_report</module>
+<modulesummary>Common Test Framework functions handling test specifications.</modulesummary>
+<description>
+<p>Common Test Framework functions handling test specifications.</p>
+  
+   <p>This module creates a junit report of the test run if plugged in
+    as a suite_callback.</p></description>
+<funcs>
+<func>
+<name>init(Opts) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="init-1"/>
+ </desc></func>
+<func>
+<name>post_end_group(Group, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="post_end_group-3"/>
+ </desc></func>
+<func>
+<name>post_end_suite(Suite, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="post_end_suite-3"/>
+ </desc></func>
+<func>
+<name>post_end_tc(TC, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="post_end_tc-3"/>
+ </desc></func>
+<func>
+<name>post_init_group(Group, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="post_init_group-3"/>
+ </desc></func>
+<func>
+<name>post_init_suite(Suite, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="post_init_suite-3"/>
+ </desc></func>
+<func>
+<name>pre_end_group(Group, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="pre_end_group-3"/>
+ </desc></func>
+<func>
+<name>pre_end_suite(Suite, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="pre_end_suite-3"/>
+ </desc></func>
+<func>
+<name>pre_init_group(Group, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="pre_init_group-3"/>
+ </desc></func>
+<func>
+<name>pre_init_suite(Suite, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="pre_init_suite-3"/>
+ </desc></func>
+<func>
+<name>pre_init_tc(TC, Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="pre_init_tc-3"/>
+ </desc></func>
+<func>
+<name>terminate(Config, State) -&gt; term()
+</name>
+<fsummary> </fsummary>
+
+<desc><marker id="terminate-2"/>
+ </desc></func></funcs>
+
+<authors>
+<aname> </aname>
+<email> </email></authors></erlref>
\ No newline at end of file
diff --git a/lib/common_test/doc/src/ct_master_chapter.xml b/lib/common_test/doc/src/ct_master_chapter.xml
index 01f8e61d36..f4f0ecad62 100644
--- a/lib/common_test/doc/src/ct_master_chapter.xml
+++ b/lib/common_test/doc/src/ct_master_chapter.xml
@@ -188,7 +188,7 @@
     <seealso marker="run_test_chapter#test_specifications">Running Test Suites</seealso>
     chapter). The result is that any test specified to run on a node with the same
     name as the Common Test node in question (typically <c>ct@somehost</c> if started
-    with the <c>run_test</c> program), will be performed. Tests without explicit
+    with the <c>ct_run</c> program), will be performed. Tests without explicit
     node association will always be performed too of course!</p>
 
     <note><p>It is recommended that absolute paths are used for log directories,
diff --git a/lib/common_test/doc/src/run_test.xml b/lib/common_test/doc/src/ct_run.xml
index 2f0a94afba..1ab563d74f 100644
--- a/lib/common_test/doc/src/run_test.xml
+++ b/lib/common_test/doc/src/ct_run.xml
@@ -21,7 +21,7 @@
 
     </legalnotice>
 
-    <title>The run_test program</title>
+    <title>The ct_run program</title>
     <prepared>Peter Andersson</prepared>
     <responsible>Peter Andersson</responsible>
     <docno></docno>
@@ -29,18 +29,18 @@
     <checked></checked>
     <date>2010-04-01</date>
     <rev>PA2</rev>
-    <file>run_test.xml</file>
+    <file>ct_run.xml</file>
   </header>
-  <com>run_test</com>
+  <com>ct_run</com>
   <comsummary>Program used for starting Common Test from the
     OS command line.
   </comsummary>
 
   <description>
-  <p>The <c>run_test</c> program is automatically installed with Erlang/OTP
+  <p>The <c>ct_run</c> program is automatically installed with Erlang/OTP
     and Common Test (please see the Installation chapter in the Common
     Test User's Guide for more information). The program accepts a number
-    of different start flags. Some flags trigger <c>run_test</c>
+    of different start flags. Some flags trigger <c>ct_run</c>
     to start the Common Test application and pass on data to it. Some
     flags start an Erlang node prepared for running Common Test in a
     particular mode.</p>
@@ -50,20 +50,20 @@
     shell (or an Erlang program). Please see the <c>ct</c> man page for
     details.</p>
 
-  <p><c>run_test</c> also accepts Erlang emulator flags. These are used
-    when <c>run_test</c> calls <c>erl</c> to start the Erlang node
+  <p><c>ct_run</c> also accepts Erlang emulator flags. These are used
+    when <c>ct_run</c> calls <c>erl</c> to start the Erlang node
     (making it possible to e.g. add directories to the code server path,
     change the cookie on the node, start additional applications, etc).</p>
 
   <p>With the optional flag:</p>
   <pre>-erl_args</pre>
-  <p>it's possible to divide the options on the <c>run_test</c> command line into
+  <p>it's possible to divide the options on the <c>ct_run</c> command line into
     two groups, one that Common Test should process (those preceding <c>-erl_args</c>),
     and one it should completely ignore and pass on directly to the emulator
     (those following <c>-erl_args</c>). Options preceding <c>-erl_args</c> that Common Test
     doesn't recognize, also get passed on to the emulator untouched.
     By means of <c>-erl_args</c> the user may specify flags with the same name, but
-    with different destinations, on the <c>run_test</c> command line.</p>
+    with different destinations, on the <c>ct_run</c> command line.</p>
   <p>If <c>-pa</c> or <c>-pz</c> flags are specified in the Common Test group of options
     (preceding <c>-erl_args</c>), relative directories will be converted to
     absolute and re-inserted into the code path by Common Test (to avoid
@@ -72,17 +72,17 @@
     following <c>-erl_args</c> on the command line. These directories are added
     to the code path normally (i.e. on specified form)</p>
 
-  <p>If <c>run_test</c> is called with option:</p>
+  <p>If <c>ct_run</c> is called with option:</p>
     <pre>-help</pre>
     <p>it prints all valid start flags to stdout.</p>
   </description>
 
-  <marker id="run_test"></marker>
+  <marker id="ct_run"></marker>
 
   <section>
     <title>Run tests from command line</title>
     <pre>
-	run_test [-dir TestDir1 TestDir2 .. TestDirN] |
+	ct_run [-dir TestDir1 TestDir2 .. TestDirN] |
 	[-suite Suite1 Suite2 .. SuiteN
 	 [[-group Group1 Group2 .. GroupN] [-case Case1 Case2 .. CaseN]]]
 	[-step [config | keep_inactive]]
@@ -110,7 +110,7 @@
   <section>
     <title>Run tests using test specification</title>
     <pre>
-	run_test -spec TestSpec1 TestSpec2 .. TestSpecN
+	ct_run -spec TestSpec1 TestSpec2 .. TestSpecN
 	[-config ConfigFile1 ConfigFile2 .. ConfigFileN]
 	[-userconfig CallbackModule1 ConfigString1 and CallbackModule2
          ConfigString2 and .. and CallbackModuleN ConfigStringN]
@@ -136,7 +136,7 @@
   <section>
     <title>Run tests in web based GUI</title>
     <pre>
-        run_test -vts [-browser Browser]
+        ct_run -vts [-browser Browser]
         [-dir TestDir1 TestDir2 .. TestDirN] |
         [-suite Suite [[-group Group] [-case Case]]]
 	[-config ConfigFile1 ConfigFile2 .. ConfigFileN]
@@ -152,12 +152,12 @@
   <section>
     <title>Refresh the HTML index files</title>
     <pre>
-	run_test -refresh_logs [-logdir LogDir] [-basic_html]</pre>
+	ct_run -refresh_logs [-logdir LogDir] [-basic_html]</pre>
   </section>
   <section>
     <title>Run CT in interactive mode</title>
     <pre>
-	run_test -shell
+	ct_run -shell
 	[-config ConfigFile1 ConfigFile2 ... ConfigFileN]
 	[-userconfig CallbackModule1 ConfigString1 and CallbackModule2
          ConfigString2 and .. and CallbackModuleN ConfigStringN]
@@ -166,7 +166,7 @@
   <section>
     <title>Start a Common Test Master node</title>
     <pre>
-	run_test -ctmaster</pre>
+	ct_run -ctmaster</pre>
   </section>
 
   <section>
diff --git a/lib/common_test/doc/src/event_handler_chapter.xml b/lib/common_test/doc/src/event_handler_chapter.xml
index 7f5144b760..904876ac46 100644
--- a/lib/common_test/doc/src/event_handler_chapter.xml
+++ b/lib/common_test/doc/src/event_handler_chapter.xml
@@ -63,12 +63,12 @@
   <section>
     <title>Usage</title>
     <p>Event handlers may be installed by means of an <c>event_handler</c>
-    start flag (<c>run_test</c>) or option (<c>ct:run_test/1</c>), where the
+    start flag (<c>ct_run</c>) or option (<c>ct:run_test/1</c>), where the
     argument specifies the names of one or more event handler modules.
     Example:</p>
-    <p><c>$ run_test -suite test/my_SUITE -event_handler handlers/my_evh1 
+    <p><c>$ ct_run -suite test/my_SUITE -event_handler handlers/my_evh1 
     handlers/my_evh2 -pa $PWD/handlers</c></p>
-    <p>Use the <c><![CDATA[run_test -event_handler_init]]></c> option instead of
+    <p>Use the <c><![CDATA[ct_run -event_handler_init]]></c> option instead of
       <c><![CDATA[-event_handler]]></c> to pass start arguments to the event handler
       init function.</p>
     <p>All event handler modules must have gen_event behaviour. Note also that 
diff --git a/lib/common_test/doc/src/install_chapter.xml b/lib/common_test/doc/src/install_chapter.xml
index 828588a673..89c497962d 100644
--- a/lib/common_test/doc/src/install_chapter.xml
+++ b/lib/common_test/doc/src/install_chapter.xml
@@ -34,8 +34,8 @@
     <title>General information</title>
 
     <p>The two main interfaces for running tests with Common Test
-      are an executable program named run_test and an
-      erlang module named <c>ct</c>. The run_test program
+      are an executable program named ct_run and an
+      erlang module named <c>ct</c>. The ct_run program
       is compiled for the underlying operating system (e.g. Unix/Linux
       or Windows) during the build of the Erlang/OTP system, and is
       installed automatically with other executable programs in
@@ -43,22 +43,22 @@
       The <c>ct</c> interface functions can be called from the Erlang shell,
       or from any Erlang function, on any supported platform.</p>
 
-    <p>A legacy Bourne shell script - also named run_test - exists,
+    <p>A legacy Bourne shell script - named run_test - exists,
       which may be manually generated and installed. This script may be used
-      instead of the run_test program mentioned above, e.g. if the user
+      instead of the ct_run program mentioned above, e.g. if the user
       wishes to modify or customize the Common Test start flags in a simpler
-      way than making changes to the run_test C program.</p>
+      way than making changes to the ct_run C program.</p>
 
     <p>The Common Test application is installed with the Erlang/OTP
       system and no additional installation step is required to start using
-      Common Test by means of the run_test executable program, and/or the interface
+      Common Test by means of the ct_run executable program, and/or the interface
       functions in the <c>ct</c> module. If you wish to use the legacy Bourne
-      shell script version of run_test, however, this script needs to be
+      shell script version run_test, however, this script needs to be
       generated first, according to the instructions below.</p>
 
     <p><note>Before reading on, please note that since Common Test version
 	1.5, the run_test shell script is no longer required for starting
-	tests with Common Test from the OS command line. The run_test
+	tests with Common Test from the OS command line. The ct_run
 	program (descibed above) is the new recommended command line interface
 	for Common Test. The shell script exists mainly for legacy reasons and
 	may not be updated in future releases of Common Test. It may even be removed.
diff --git a/lib/common_test/doc/src/ref_man.xml b/lib/common_test/doc/src/ref_man.xml
index 8be234d979..d5985bb021 100644
--- a/lib/common_test/doc/src/ref_man.xml
+++ b/lib/common_test/doc/src/ref_man.xml
@@ -63,7 +63,7 @@
       Server application.</p>
   </description>
   <xi:include href="common_test_app.xml"/>
-  <xi:include href="run_test.xml"/>
+  <xi:include href="ct_run.xml"/>
   <!-- If you make modifications in the module list below,
        you also need to update CT_MODULES in Makefile. -->
   <xi:include href="ct.xml"/>
diff --git a/lib/common_test/doc/src/run_test_chapter.xml b/lib/common_test/doc/src/run_test_chapter.xml
index 1efff25f5b..94fcf6bf01 100644
--- a/lib/common_test/doc/src/run_test_chapter.xml
+++ b/lib/common_test/doc/src/run_test_chapter.xml
@@ -71,7 +71,7 @@
 
     <p>If test suites or help modules include header files stored in other
       locations than the test directory, you may specify these include directories
-      by means of the <c><![CDATA[-include]]></c> flag with <c><![CDATA[run_test]]></c>, 
+      by means of the <c><![CDATA[-include]]></c> flag with <c><![CDATA[ct_run]]></c>, 
       or the <c><![CDATA[include]]></c> option with <c><![CDATA[ct:run_test/1]]></c>.
       In addition to this, an include path may be specified with an OS
       environment variable; <c><![CDATA[CT_INCLUDE_PATH]]></c>. Example (bash):</p>
@@ -93,7 +93,7 @@
       there instead.</p>
 
     <p>It is possible to disable the automatic compilation feature by using the
-      <c><![CDATA[-no_auto_compile]]></c> flag with <c><![CDATA[run_test]]></c>, or
+      <c><![CDATA[-no_auto_compile]]></c> flag with <c><![CDATA[ct_run]]></c>, or
       the <c><![CDATA[{auto_compile,false}]]></c> option with 
       <c><![CDATA[ct:run_test/1]]></c>. With automatic compilation
       disabled, the user is responsible for compiling the test suite modules 
@@ -108,26 +108,26 @@
   <section>
     <title>Running tests from the OS command line</title>
     
-    <p>The <c>run_test</c> program can be used for running tests from
+    <p>The <c>ct_run</c> program can be used for running tests from
       the OS command line, e.g.
     </p>
     <list>
-      <item><c><![CDATA[run_test -config <configfilenames> -dir <dirs>]]></c></item>
-      <item><c><![CDATA[run_test -config <configfilenames> -suite <suiteswithfullpath>]]></c>
+      <item><c><![CDATA[ct_run -config <configfilenames> -dir <dirs>]]></c></item>
+      <item><c><![CDATA[ct_run -config <configfilenames> -suite <suiteswithfullpath>]]></c>
       </item>
-      <item><c><![CDATA[run_test -userconfig <callbackmodulename> <configfilenames> -suite <suiteswithfullpath>]]></c>
+      <item><c><![CDATA[ct_run -userconfig <callbackmodulename> <configfilenames> -suite <suiteswithfullpath>]]></c>
       </item>
-      <item><c><![CDATA[run_test -config <configfilenames> -suite <suitewithfullpath>
+      <item><c><![CDATA[ct_run -config <configfilenames> -suite <suitewithfullpath>
 	      -group <groupnames> -case <casenames>]]></c></item>
     </list>
     <p>Examples:</p>
-    <p><c>$ run_test -config $CFGS/sys1.cfg $CFGS/sys2.cfg -dir $SYS1_TEST $SYS2_TEST</c></p>
-    <p><c>$ run_test -userconfig ct_config_xml $CFGS/sys1.xml $CFGS/sys2.xml -dir $SYS1_TEST $SYS2_TEST</c></p>
-    <p><c>$ run_test -suite $SYS1_TEST/setup_SUITE $SYS2_TEST/config_SUITE</c></p>
-    <p><c>$ run_test -suite $SYS1_TEST/setup_SUITE -case start stop</c></p>
-    <p><c>$ run_test -suite $SYS1_TEST/setup_SUITE -group installation -case start stop</c></p>
+    <p><c>$ ct_run -config $CFGS/sys1.cfg $CFGS/sys2.cfg -dir $SYS1_TEST $SYS2_TEST</c></p>
+    <p><c>$ ct_run -userconfig ct_config_xml $CFGS/sys1.xml $CFGS/sys2.xml -dir $SYS1_TEST $SYS2_TEST</c></p>
+    <p><c>$ ct_run -suite $SYS1_TEST/setup_SUITE $SYS2_TEST/config_SUITE</c></p>
+    <p><c>$ ct_run -suite $SYS1_TEST/setup_SUITE -case start stop</c></p>
+    <p><c>$ ct_run -suite $SYS1_TEST/setup_SUITE -group installation -case start stop</c></p>
     
-    <p>Other flags that may be used with <c>run_test</c>:</p>
+    <p>Other flags that may be used with <c>ct_run</c>:</p>
     <list>
       <item><c><![CDATA[-logdir <dir>]]></c>, specifies where the HTML log files are to be written.</item>
       <item><c><![CDATA[-label <name_of_test_run>]]></c>, associates the test run with a name that gets printed
@@ -167,20 +167,20 @@
     <note><p>Directories passed to Common Test may have either relative or absolute paths.</p></note>
 
     <note><p>Arbitrary start flags to the Erlang Runtime System may also be passed as
-             parameters to <c>run_test</c>. It is, for example, useful to be able to
+             parameters to <c>ct_run</c>. It is, for example, useful to be able to
 	     pass directories that should be added to the Erlang code server search path
 	     with the <c>-pa</c> or <c>-pz</c> flag. If you have common help- or library 
 	     modules for test suites (separately compiled), stored in other directories 
 	     than the test suite directories, these help/lib directories are preferrably
 	     added to the code path this way. Example:</p>
-	  <p><c>$ run_test -dir ./chat_server -logdir ./chat_server/testlogs -pa $PWD/chat_server/ebin</c></p>
+	  <p><c>$ ct_run -dir ./chat_server -logdir ./chat_server/testlogs -pa $PWD/chat_server/ebin</c></p>
 	  <p>Note how in this example, the absolute path of the <c>chat_server/ebin</c>
 	     directory is passed to the code server. This is essential since relative
 	     paths are stored by the code server as relative, and Common Test changes 
 	     the current working directory of the Erlang Runtime System during the test run!</p>
     </note>
     
-    <p>For more information about the <c>run_test</c> program, see the
+    <p>For more information about the <c>ct_run</c> program, see the
       <seealso marker="install_chapter#general">Installation</seealso> chapter.
     </p>
   </section>
@@ -188,7 +188,7 @@
   <section>
     <title>Running tests from the Web based GUI</title>
     
-    <p>The web based GUI, VTS, is started with the <c>run_test</c>
+    <p>The web based GUI, VTS, is started with the <c>ct_run</c>
       program. From the GUI you can load config files, and select
       directories, suites and cases to run. You can also state the
       config files, directories, suites and cases on the command line
@@ -196,22 +196,22 @@
     </p>
     
     <list>
-      <item><c>run_test -vts</c></item>
-      <item><c><![CDATA[run_test -vts -config <configfilename>]]></c></item>
-      <item><c><![CDATA[run_test -vts -config <configfilename> -suite <suitewithfullpath>
+      <item><c>ct_run -vts</c></item>
+      <item><c><![CDATA[ct_run -vts -config <configfilename>]]></c></item>
+      <item><c><![CDATA[ct_run -vts -config <configfilename> -suite <suitewithfullpath>
 	      -case <casename>]]></c></item>
     </list>
     
     <p>From the GUI you can run tests and view the result and the logs.
     </p>
     
-    <p>Note that <c>run_test -vts</c> will try to open the Common Test start
+    <p>Note that <c>ct_run -vts</c> will try to open the Common Test start
       page in an existing web browser window or start the browser if it is
       not running. Which browser should be started may be specified with
       the browser start command option:</p>
-      <p><c><![CDATA[run_test -vts -browser <browser_start_cmd>]]></c></p>
+      <p><c><![CDATA[ct_run -vts -browser <browser_start_cmd>]]></c></p>
       <p>Example:</p>
-      <p><c><![CDATA[$ run_test -vts -browser 'firefox&']]></c></p>
+      <p><c><![CDATA[$ ct_run -vts -browser 'firefox&']]></c></p>
       <p>Note that the browser must run as a separate OS process or VTS will hang!</p>
       <p>If no specific browser start command is specified, Firefox will
         be the default browser on Unix platforms and Internet Explorer on Windows.
@@ -227,10 +227,10 @@
     <p>Common Test provides an Erlang API for running tests. The main (and most
       flexible) function for specifying and executing tests is called
       <c>ct:run_test/1</c>. This function takes the same start parameters as
-      the <c>run_test</c> program described above, only the flags are instead
+      the <c>ct_run</c> program described above, only the flags are instead
       given as options in a list of key-value tuples. E.g. a test specified 
-      with <c>run_test</c> like:</p>
-      <p><c>$ run_test -suite ./my_SUITE -logdir ./results</c></p> 
+      with <c>ct_run</c> like:</p>
+      <p><c>$ ct_run -suite ./my_SUITE -logdir ./results</c></p> 
       <p>is with <c>ct:run_test/1</c> specified as:</p> 
       <p><c>1> ct:run_test([{suite,"./my_SUITE"},{logdir,"./results"}]).</c></p>
       <p>For detailed documentation, please see the <c>ct</c> manual page.</p>    
@@ -253,17 +253,17 @@
       manually and call <c>ct:install/1</c> to install any configuration
       data you might need (use <c>[]</c> as argument otherwise), then
       call <c>ct:start_interactive/0</c> to start Common Test. If you use
-      the <c>run_test</c> program, you may start the Erlang shell and Common Test
+      the <c>ct_run</c> program, you may start the Erlang shell and Common Test
       in the same go by using the <c>-shell</c> and, optionally, the <c>-config</c>
       and/or <c>-userconfig</c> flag. Examples:
     </p>
     <list>
-      <item><c>run_test -shell</c></item>
-      <item><c><![CDATA[run_test -shell -config cfg/db.cfg]]></c></item>
-      <item><c><![CDATA[run_test -shell -userconfig db_login testuser x523qZ]]></c></item>
+      <item><c>ct_run -shell</c></item>
+      <item><c><![CDATA[ct_run -shell -config cfg/db.cfg]]></c></item>
+      <item><c><![CDATA[ct_run -shell -userconfig db_login testuser x523qZ]]></c></item>
     </list>
     
-    <p>If no config file is given with the <c>run_test</c> command,
+    <p>If no config file is given with the <c>ct_run</c> command,
       a warning will be displayed. If Common Test has been run from the same
       directory earlier, the same config file(s) will be used
       again. If Common Test has not been run from this directory before, no
@@ -293,7 +293,7 @@
       <c>ctlog.html</c> in the <c><![CDATA[ct_run.<timestamp>]]></c>
       directory. A link to this file will be available in the file
       named <c>last_interactive.html</c> in the directory from which
-      you executed <c>run_test</c>. Currently, specifying a different
+      you executed <c>ct_run</c>. Currently, specifying a different
       root directory for the logs than the current working directory,
       is not supported.</p>
     
@@ -309,7 +309,7 @@
   <section>
     <title>Step by step execution of test cases with the Erlang Debugger</title>
    
-    <p>By means of <c>run_test -step [opts]</c>, or by passing the 
+    <p>By means of <c>ct_run -step [opts]</c>, or by passing the 
        <c>{step,Opts}</c> option to <c>ct:run_test/1</c>, it is possible
        to get the Erlang Debugger started automatically and use its
        graphical interface to investigate the state of the current test 
@@ -345,12 +345,12 @@
       for <c>ct</c>). There are two general types of terms:
       configuration terms and test specification terms.</p>
     <p>With configuration terms it is possible to e.g. label the test
-      run (similar to <c>run_test -label</c>), evaluate arbitrary expressions
+      run (similar to <c>ct_run -label</c>), evaluate arbitrary expressions
       before starting a test, import configuration
       data (similar to
-      <c>run_test -config/-userconfig</c>), specify HTML log directories (similar
+      <c>ct_run -config/-userconfig</c>), specify HTML log directories (similar
       to
-      <c>run_test -logdir</c>), give aliases to test nodes and test
+      <c>ct_run -logdir</c>), give aliases to test nodes and test
       directories (to make a specification easier to read and
       maintain), enable code coverage analysis (see
       the <seealso marker="cover_chapter#cover">Code Coverage
@@ -359,7 +359,7 @@
       Event Handling</seealso> chapter). There is also a term for
       specifying include directories that should be passed on to the
       compiler when automatic compilation is performed (similar
-      to <c>run_test -include</c>, see above).</p>
+      to <c>ct_run -include</c>, see above).</p>
     <p>With test specification terms it is possible to state exactly
       which tests should run and in which order. A test term specifies
       either one or more suites, one or more test case groups, or one
@@ -535,7 +535,7 @@
     <p>It is possible for the user to provide a test specification that
       includes (for Common Test) unrecognizable terms. If this is desired,
       the <c>-allow_user_terms</c> flag should be used when starting tests with
-      <c>run_test</c>. This forces Common Test to ignore unrecognizable terms.
+      <c>ct_run</c>. This forces Common Test to ignore unrecognizable terms.
       Note that in this mode, Common Test is not able to check the specification 
       for errors as efficiently as if the scanner runs in default mode. 
       If <c>ct:run_test/1</c> is used for starting the tests, the relaxed scanner 
@@ -661,11 +661,11 @@
 	</pre>
 
 	<p>To install the CSS file (Common Test inlines the definition in the 
-	  HTML code), the name may be provided when executing <c>run_test</c>.
+	  HTML code), the name may be provided when executing <c>ct_run</c>.
 	  Example:</p>
 
 	<pre>
-	  $ run_test -dir $TEST/prog -stylesheet $TEST/styles/test_categories.css
+	  $ ct_run -dir $TEST/prog -stylesheet $TEST/styles/test_categories.css
 	</pre>
 
 	  <p>Categories in a CSS file installed with the <c>-stylesheet</c> flag
@@ -738,7 +738,7 @@
        means of time, it is also possible to specify what action Common Test should 
        take upon timeout. Either Common Test performs all tests in the current run before stopping, 
        or it stops as soon as the current test job is finished. Repetition can be activated by
-       means of <c>run_test</c> start flags, or tuples in the <c>ct:run:test/1</c>
+       means of <c>ct_run</c> start flags, or tuples in the <c>ct:run:test/1</c>
        option list argument. The flags (options in parenthesis) are:</p>
        <list>
        <item><c>-repeat N ({repeat,N})</c>, where <c>N</c> is a positive integer.</item>
@@ -774,7 +774,7 @@
 
        <p>Example 1:</p>
        <pre>
-          $ run_test -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -duration 001000 -force_stop</pre>
+          $ ct_run -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -duration 001000 -force_stop</pre>
        <p>Here the suites in test directory to1, followed by the suites in to2, will be executed 
           in one test run. A timeout event will occur after 10 minutes. As long as there is time 
 	  left, Common Test will repeat the test run (i.e. starting over with the to1 test). 
@@ -787,7 +787,7 @@
           $ date
 	  Fri Sep 28 15:00:00 MEST 2007
 
-          $ run_test -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -until 160000</pre>
+          $ ct_run -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -until 160000</pre>
        <p>Here the same test run as in the example above will be executed (and possibly repeated). 
           In this example, however, the timeout will occur after 1 hour and when that happens,
 	  Common Test will finish the entire test run before stopping (i.e. the to1 and to2 test
@@ -795,7 +795,7 @@
        
        <p>Example 3:</p>
        <pre>
-          $ run_test -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -repeat 5</pre>
+          $ ct_run -dir $TEST_ROOT/to1 $TEST_ROOT/to2 -repeat 5</pre>
        <p>Here the test run, including both the to1 and the to2 test, will be repeated 5 times.</p>
 
        <note><p>This feature should not be confused with the <c>repeat</c> property of a test
@@ -814,7 +814,7 @@
 	of the <c>-silent_connections</c> flag:</p>
       
       <pre>
-	run_test -silent_connections [conn_types]
+	ct_run -silent_connections [conn_types]
       </pre>
       
       <p>where <c>conn_types</c> specifies <c>telnet, ftp, rpc</c> and/or <c>snmp</c>.</p>
@@ -822,11 +822,11 @@
       <p>Example:</p>
       
       <pre>
-	run_test ... -silent_connections telnet ftp</pre>
+	ct_run ... -silent_connections telnet ftp</pre>
       <p>switches off logging for telnet and ftp connections.</p>
       
       <pre>
-	run_test ... -silent_connections</pre>
+	ct_run ... -silent_connections</pre>
       <p>switches off logging for all connection types.</p>
       
       
diff --git a/lib/common_test/doc/src/test_structure_chapter.xml b/lib/common_test/doc/src/test_structure_chapter.xml
index cd38ae0c7c..b9ca59135d 100644
--- a/lib/common_test/doc/src/test_structure_chapter.xml
+++ b/lib/common_test/doc/src/test_structure_chapter.xml
@@ -144,7 +144,7 @@
 	be used when the test suite needs to write to files.
       </item>
 
-      <tag><em>run_test</em></tag>
+      <tag><em>ct_run</em></tag>
       <item>
         The name of an executable program that may be
 	used as an interface for specifying and running