UG: Use 'Rebot' instead of 'rebot' when referring to Rebot tool, not command.

pekkaklarck · pekkaklarck · commit 11206e500300 · 2015-12-30T20:04:11.000+02:00
diff --git a/doc/userguide/src/ExecutingTestCases/BasicUsage.rst b/doc/userguide/src/ExecutingTestCases/BasicUsage.rst
@@ -4,7 +4,7 @@ Basic usage
 Robot Framework test cases are executed from the command line, and the
 end result is, by default, an `output file`_ in XML format and an HTML
 report_ and log_. After the execution, output files can be combined and
-otherwise `post-processed`__ with the ``rebot`` tool.
+otherwise `post-processed`__ with the Rebot tool.
 
 __ `Post-processing outputs`_
 
@@ -228,7 +228,7 @@ post-processing`__, respectively. The options and their values must be
 defined as a space separated list and they are placed in front of any
 explicit options on the command line. The main use case for these
 environment variables is setting global default values for certain options to
-avoid the need to repeat them every time tests are run or ``rebot`` used.
+avoid the need to repeat them every time tests are run or Rebot used.
 
 .. sourcecode:: bash
 
@@ -324,7 +324,7 @@ the :option:`--NoStatusRC` command line option. This might be useful, for
 example, in continuous integration servers where post-processing of results
 is needed before the overall status of test execution can be determined.
 
-.. note:: Same return codes are also used with rebot_.
+.. note:: Same return codes are also used with Rebot_.
 
 Errors and warnings during execution
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -533,8 +533,8 @@ another:
 
 Implementing the above example with Windows batch files is not very
 complicated, either. The most important thing to remember is that
-because ``robot`` and ``rebot`` are implemented as batch
-files, ``call`` must be used when running them from another batch
+because ``robot`` and ``rebot`` scripts are implemented as batch files on
+Windows, ``call`` must be used when running them from another batch
 file. Otherwise execution would end when the first batch file is
 finished.
 
diff --git a/doc/userguide/src/ExecutingTestCases/ConfiguringExecution.rst b/doc/userguide/src/ExecutingTestCases/ConfiguringExecution.rst
@@ -17,7 +17,7 @@ Selecting test cases
 
 Robot Framework offers several command line options for selecting
 which test cases to execute. The same options also work when
-post-processing outputs with the ``rebot`` tool.
+post-processing outputs with Rebot_.
 
 By test suite and test case names
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -155,10 +155,10 @@ also in this case. As a result normal outputs are created but show zero
 executed tests. The same option can be used also to alter the behavior when
 an empty directory or a test case file containing no tests is executed.
 
-Similar situation can occur also when processing output files with rebot_.
+Similar situation can occur also when processing output files with Rebot_.
 It is possible that no test match the used filtering criteria or that
 the output file contained no tests to begin with. By default executing
-``rebot`` fails in these cases, but it has a separate
+Rebot fails in these cases, but it has a separate
 :option:`--ProcessEmptySuite` option that can be used to alter the behavior.
 In practice this option works the same way as :option:`--RunEmptySuite` when
 running tests.
@@ -205,7 +205,7 @@ they start to pass.
 
 Criticality set when tests are
 executed is not stored anywhere. If you want to keep same criticality
-when `post-processing outputs`_ with ``rebot``, you need to
+when `post-processing outputs`_ with Rebot, you need to
 use :option:`--critical` and/or :option:`--noncritical` also with it::
 
   # Use rebot to create new log and report from the output created during execution
diff --git a/doc/userguide/src/ExecutingTestCases/OutputFiles.rst b/doc/userguide/src/ExecutingTestCases/OutputFiles.rst
@@ -267,11 +267,11 @@ threshold level. A special value `NONE` can also be used to
 disable logging altogether.
 
 It is possible to use the :option:`--loglevel` option also when
-`post-processing outputs`_ with ``rebot``. This allows, for example,
+`post-processing outputs`_ with Rebot. This allows, for example,
 running tests initially with the `TRACE` level, and generating smaller
 log files for normal viewing later with the `INFO` level. By default
 all the messages included during execution will be included also with
-``rebot``. Messages ignored during the execution cannot be recovered.
+Rebot. Messages ignored during the execution cannot be recovered.
 
 Another possibility to change the log level is using the BuiltIn_
 keyword :name:`Set Log Level` in the test data. It takes the same
@@ -556,15 +556,15 @@ deeply nested keyword structures.
 Setting start and end time of execution
 ---------------------------------------
 
-When `combining outputs`_ using ``rebot``, it is possible to set the start
+When `combining outputs`_ using Rebot, it is possible to set the start
 and end time of the combined test suite using the options :option:`--starttime`
 and :option:`--endtime`, respectively. This is convenient, because by default,
 combined suites do not have these values. When both the start and end time are
 given, the elapsed time is also calculated based on them. Otherwise the elapsed
 time is got by adding the elapsed times of the child test suites together.
 
 It is also possible to use the above mentioned options to set start and end
-times for a single suite when using ``rebot``.  Using these options with a
+times for a single suite when using Rebot.  Using these options with a
 single output always affects the elapsed time of the suite.
 
 Times must be given as timestamps in the format `YYYY-MM-DD
diff --git a/doc/userguide/src/ExecutingTestCases/PostProcessing.rst b/doc/userguide/src/ExecutingTestCases/PostProcessing.rst
@@ -4,7 +4,7 @@ Post-processing outputs
 =======================
 
 `XML output files`_ that are generated during the test execution can be
-post-processed afterwards by the ``rebot`` tool, which is an integral
+post-processed afterwards by the Rebot tool, which is an integral
 part of Robot Framework. It is used automatically when test
 reports and logs are generated during the test execution, and using it
 separately allows creating custom reports and logs as well as combining
@@ -14,8 +14,8 @@ and merging results.
    :depth: 2
    :local:
 
-Using ``rebot`` tool
---------------------
+Using Rebot
+-----------
 
 Synopsis
 ~~~~~~~~
@@ -37,22 +37,22 @@ any interpreter, or use the `standalone JAR distribution`_.
 Specifying options and arguments
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The basic syntax for using ``rebot`` is exactly the same as when
+The basic syntax for using Rebot is exactly the same as when
 `starting test execution`_ and also most of the command line options are
-identical. The main difference is that arguments to ``rebot`` are
+identical. The main difference is that arguments to Rebot are
 `XML output files`_ instead of test data files or directories.
 
-Return codes with ``rebot``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Return codes with Rebot
+~~~~~~~~~~~~~~~~~~~~~~~
 
-Return codes from ``rebot`` are exactly same as when `running tests`__.
+Return codes from Rebot are exactly same as when `running tests`__.
 
 __ `Return codes`_
 
 Creating different reports and logs
 -----------------------------------
 
-You can use ``rebot`` for creating the same reports and logs that
+You can use Rebot for creating the same reports and logs that
 are created automatically during the test execution. Of course, it is
 not sensible to create the exactly same files, but, for example,
 having one report with all test cases and another with only some
@@ -69,12 +69,12 @@ for example, be executed on different environments, output files collected
 to a central place, and reports and logs created there. This approach can
 also work very well if generating reports and logs takes a lot of time when
 running tests on Jython. Disabling log and report generation and generating
-them later with ``rebot`` can save a lot of time and use less memory.
+them later with Rebot can save a lot of time and use less memory.
 
 Combining outputs
 -----------------
 
-An important feature in ``rebot`` is its ability to combine
+An important feature in Rebot is its ability to combine
 outputs from different test execution rounds. This capability allows,
 for example, running the same test cases on different environments and
 generating an overall report from all outputs. Combining outputs is
@@ -105,7 +105,7 @@ If same tests are re-executed or a single test suite executed in pieces,
 combining results like discussed above creates an unnecessary top-level
 test suite. In these cases it is typically better to merge results instead.
 Merging is done by using :option:`--merge` option which changes the way how
-``rebot`` combines two or more output files. This option itself takes no
+Rebot combines two or more output files. This option itself takes no
 arguments and all other command line options can be used with it normally::
 
    rebot --merge --name Example --critical regression original.xml merged.xml
@@ -126,7 +126,7 @@ Combining re-execution results with the original results using the default
 `combining outputs`_ approach does not work too well. The main problem is
 that you get separate test suites and possibly already fixed failures are
 also shown. In this situation it is better to use :option:`--merge (-R)`
-option to tell ``rebot`` to merge the results instead. In practice this
+option to tell Rebot to merge the results instead. In practice this
 means that tests from the latter test runs replace tests in the original.
 The usage is best illustrated by a practical example using
 :option:`--rerunfailed` and :option:`--merge` together::
