Unify get-config

src/suite-design-guide/efficiency.rst

@@ -78,7 +78,7 @@ Cylc provides tools to help make sense of your inheritance hierarchy:
 
 - ``cylc graph -n/--namespaces`` - plot the full multiple
   inheritance graph (not the dependency graph)
-- ``cylc get-config SUITE`` - print selected sections or items
+- ``cylc config SUITE`` - print selected sections or items
   after inheritance processing
 - ``cylc graph SUITE`` - plot the dependency graph, with
   collapsible first-parent families

src/suites/inherit/multi/one/flow.cylc

@@ -8,8 +8,8 @@
         $ cylc graph -n SUITE # graph namespaces
         $ cylc graph SUITE # dependencies, collapse on first-parent namespaces
 
-        $ cylc get-config --sparse --item [runtime]ops_s1 SUITE
-        $ cylc get-config --sparse --item [runtime]var_p2 foo
+        $ cylc config --sparse --item [runtime]ops_s1 SUITE
+        $ cylc config --sparse --item [runtime]var_p2 foo
     """
 
 [scheduling]
@@ -33,7 +33,7 @@
 
     [[ops_p1, ops_p2]]
         inherit = OPS, PARALLEL
-        
+
     [[var_s1, var_s2]]
         inherit = VAR, SERIAL
 
@@ -42,7 +42,7 @@
 
 [visualization]
     # NOTE ON VISUALIZATION AND MULTIPLE INHERITANCE: overlapping
-    # family groups can have overlapping attributes, so long as 
+    # family groups can have overlapping attributes, so long as
     # non-conflicting attributes are used to style each group. Below,
     # for example, OPS tasks are filled green and SERIAL tasks are
     # outlined blue, so that ops_s1 and ops_s2 are green with a blue

src/suites/inherit/single/two/flow.cylc

@@ -3,7 +3,7 @@
 
     description = """
         This suite illustrates several tiers of task runtime inheritance.
-        To see the result, use 'cylc get-config'.
+        To see the result, use 'cylc config SUITE'.
     """
 
 [scheduling]

src/tutorial/furthertopics/inheritance.rst

@@ -132,9 +132,9 @@ Cylc handles inheritance by starting with the root family and working down the
 inheritance tree applying each section in turn.
 
 To see the resulting configuration for the ``a380`` task use the
-``cylc get-config`` command::
+``cylc config`` command::
 
-   cylc get-config . --sparse -i "[runtime][a380]"
+   cylc config . --sparse -i "[runtime][a380]"
 
 You should see some settings which have been inherited from the ``VEHICLE`` and
 ``AIRPLANE`` families as well as a couple defined in the ``a380`` task.
@@ -227,14 +227,14 @@ The inheritance hierarchy should now look like this:
    AIR_VEHICLE -> AIRPLANE  [color=royalblue];
    AIR_VEHICLE -> HELICOPTER   [color=royalblue];
 
-Inspect the configuration of the ``v22`` task using the ``cylc get-config``
+Inspect the configuration of the ``v22`` task using the ``cylc config``
 command.
 
 .. spoiler:: Hint warning
 
    .. code-block:: bash
 
-      cylc get-config . --sparse -i "[runtime][v22]"
+      cylc config . --sparse -i "[runtime][v22]"
 
 You should see that the ``CAN_TASK_OFF_VERTICALLY`` environment variable has
 been set to ``false`` which isn't right. This is because of the order in which
@@ -273,7 +273,7 @@ in the ``AIRPLANE`` family.
    HELICOPTER   # sets "CAN_TAKE_OFF_VERTICALLY to "true"
    v22
 
-Inspect the configuration of the ``v22`` task using ``cylc get-config`` to
+Inspect the configuration of the ``v22`` task using ``cylc config`` to
 confirm this.
 
 
@@ -414,7 +414,7 @@ task.
                  title = An old-fashioned bicycle.
 
 
-Using ``cylc get-config`` to inspect the configuration of the ``penny_farthing``
+Using ``cylc config`` to inspect the configuration of the ``penny_farthing``
 task we can see that it inherits settings from the ``VEHICLE``,
 ``BICYCLE`` and ``HUMAN_ENGINE`` families.
 
@@ -434,7 +434,7 @@ task we can see that it inherits settings from the ``VEHICLE``,
 
    .. code-block:: bash
 
-      cylc get-config . --sparse -i "[runtime]penny_farthing"
+      cylc config . --sparse -i "[runtime]penny_farthing"
 
 Hovercraft
 ^^^^^^^^^^

src/tutorial/runtime/configuration-consolidation/families.rst

@@ -311,12 +311,12 @@ Families and ``cylc graph``
          -        DOMAIN = -12,48,5,61  # Do not change!
 
       To ensure that the environment variables are being inherited correctly
-      by the tasks, inspect the ``[runtime]`` section using ``cylc get-config``
+      by the tasks, inspect the ``[runtime]`` section using ``cylc config``
       by running the following command:
 
       .. code-block:: bash
 
-         cylc get-config . --sparse -i "[runtime]"
+         cylc config . --sparse -i "[runtime]"
 
       You should see the environment variables from the ``[root]`` section
       in the ``[environment]`` section for all tasks.
@@ -326,4 +326,4 @@ Families and ``cylc graph``
          You may find it easier to open the output of this command in a text
          editor, e.g::
 
-            cylc get-config . --sparse -i "[runtime]" | gvim -
+            cylc config . --sparse -i "[runtime]" | gvim -

src/tutorial/runtime/configuration-consolidation/index.rst

@@ -82,33 +82,34 @@ structure of a suite and avoid duplication.
    parameters
 
 
-The ``cylc get-config`` Command
--------------------------------
+The ``cylc config`` Command
+---------------------------
 
 .. ifnotslides::
 
-   The ``cylc get-config`` command reads in then prints out the :cylc:conf:`flow.cylc` file
-   to the terminal.
+   The ``cylc config`` command reads in either the
+   :cylc:conf:`global.cylc` file, or a specific workflow's :cylc:conf:`flow.cylc`
+   file, and it prints out the configuration to the terminal.
 
    Throughout this section we will be introducing methods for consolidating
-   the :cylc:conf:`flow.cylc` file, the ``cylc get-config`` command can be used to
+   the :cylc:conf:`flow.cylc` file, the ``cylc config`` command can be used to
    "expand" the :cylc:conf:`flow.cylc` file back to its full form.
 
    .. note::
 
-      The main use of ``cylc get-config`` is inspecting the
-      ``[runtime]`` section of a suite. The ``cylc get-config`` command does not
+      Often, the main use of ``cylc config`` is inspecting the
+      ``[runtime]`` section of a workflow. The ``cylc config`` command does not
       expand :term:`parameterisations <parameterisation>` and
-      :term:`families <family>` in the suite's :term:`graph`. To inspect the
+      :term:`families <family>` in the workflow's :term:`graph`. To inspect the
       graphing use the ``cylc graph`` command.
 
-   Call ``cylc get-config`` with the path of the suite (``.`` if you are already
-   in the :term:`suite directory`) and the ``--sparse`` option which hides
+   Call ``cylc config`` with the path of the workflow (``.`` if you are already
+   in the :term:`run directory`) and the ``--sparse`` option which hides
    default values.
 
 .. code-block:: sub
 
-   cylc get-config <path> --sparse
+   cylc config <path> --sparse
 
 .. ifnotslides::
 
@@ -118,20 +119,20 @@ The ``cylc get-config`` Command
 .. code-block:: sub
 
    # Print the contents of the [scheduling] section.
-   cylc get-config <path> --sparse -i '[scheduling]'
+   cylc config <path> --sparse -i '[scheduling]'
    # Print the contents of the get_observations_heathrow task.
-   cylc get-config <path> --sparse -i '[runtime][get_observations_heathrow]'
+   cylc config <path> --sparse -i '[runtime][get_observations_heathrow]'
    # Print the value of the script setting in the get_observations_heathrow task
-   cylc get-config <path> --sparse -i '[runtime][get_observations_heathrow]script'
+   cylc config <path> --sparse -i '[runtime][get_observations_heathrow]script'
 
 .. nextslide::
 
 .. ifslides::
 
-   Note that ``cylc get-config`` doesn't expand families or parameterisations
+   Note that ``cylc config`` doesn't expand families or parameterisations
    in the :term:`graph`. Use ``cylc graph`` to visualise these.
 
-   .. TODO - Raise and issue for this, note cylc get-config and cylc view.
+   .. TODO - Raise and issue for this, note cylc config and cylc view.
 
 
 The Three Approaches

src/tutorial/runtime/configuration-consolidation/jinja2.rst

@@ -232,5 +232,5 @@ This would result in:
          -            API_KEY = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
          +            API_KEY = {{ API_KEY }}
 
-      Check the result with ``cylc get-config``. The Jinja2 will be processed
+      Check the result with ``cylc config``. The Jinja2 will be processed
       so you should not see any difference after making these changes.

src/tutorial/runtime/configuration-consolidation/parameters.rst

@@ -222,13 +222,13 @@ Parameters can be either words or integers:
              [[[environment]]]
                  API_KEY = {{ API_KEY }}
 
-      Using ``cylc get-config`` you should see that Cylc replaces the
+      Using ``cylc config`` you should see that Cylc replaces the
       ``<station>`` with each of the stations in turn, creating a new task for
       each:
 
       .. code-block:: bash
 
-         cylc get-config . --sparse -i "[runtime]"
+         cylc config . --sparse -i "[runtime]"
 
       The ``get_observations`` tasks are now missing the ``SITE_ID``
       environment variable. Add a new section for each station with a
@@ -266,12 +266,12 @@ Parameters can be either words or integers:
                 [[[environment]]]
                     SITE_ID = 3005
 
-      Using ``cylc get-config`` you should now see four ``get_observations``
+      Using ``cylc config`` you should now see four ``get_observations``
       tasks, each with a ``script``, an ``API_KEY`` and a ``SITE_ID``:
 
       .. code-block:: bash
 
-         cylc get-config . --sparse -i "[runtime]"
+         cylc config . --sparse -i "[runtime]"
 
       Finally we can use this parameterisation to simplify the suite's
       graphing. Replace the ``get_observations`` lines in the graph with
@@ -290,7 +290,7 @@ Parameters can be either words or integers:
 
       .. hint::
 
-         The ``cylc get-config`` command does not expand parameters or families
+         The ``cylc config`` command does not expand parameters or families
          in the graph so you must use ``cylc graph`` to inspect changes to the
          graphing.
 

src/tutorial/runtime/introduction.rst

@@ -84,7 +84,7 @@ We can also call other scripts or executables in this way, e.g:
    It is often a good idea to keep our scripts with the Cylc suite rather than
    leaving them somewhere else on the system.
 
-   If you create a ``bin/`` sub-directory within the :term:`suite directory`
+   If you create a ``bin/`` sub-directory within the :term:`source directory`,
    Cylc will automatically prepend it to the ``PATH`` environment
    variable when the task runs.
 
@@ -316,7 +316,7 @@ Running A Suite
 
 .. ifnotslides::
 
-   The ``name`` is the name of the :term:`suite directory` (i.e. ``<name>``
+   The ``name`` is the name of the :term:`run directory` (i.e. ``<name>``
    would be ``foo`` in the above example).
 
 .. note::

src/tutorial/runtime/runtime-configuration.rst

@@ -415,7 +415,7 @@ Start, Stop, Restart
 
       The runtime configuration for the remaining tasks has been written out
       for you in the ``runtime`` file which you will find in the
-      :term:`suite directory`. Copy the code in the ``runtime`` file to the
+      :term:`run directory`. Copy the code in the ``runtime`` file to the
       bottom of the :cylc:conf:`flow.cylc` file.
 
       Check the :cylc:conf:`flow.cylc` file is valid by running the command:

src/tutorial/scheduling/graphing.rst

@@ -323,7 +323,7 @@ Cylc Graphs
          ~/cylc-run
 
       Within this directory create a new folder called ``graph-introduction``,
-      which is to be our :term:`suite directory`. Move into it:
+      which is to be our :term:`run directory`. Move into it:
 
       .. code-block:: bash
 
@@ -369,7 +369,7 @@ Cylc Graphs
          :class: hint
 
          ``cylc graph`` takes the path to the suite as an argument. As we are
-         inside the :term:`suite directory` we can run ``cylc graph .``.
+         inside the :term:`run directory` we can run ``cylc graph .``.
 
       If the results don't match the diagram above try going back to the
       :cylc:conf:`flow.cylc` file and making changes.

src/user-guide/writing-suites/configuration.rst

@@ -19,7 +19,7 @@ Here we will look at:
 Suite Configuration Directories
 -------------------------------
 
-A Cylc :term:`suite directory` contains:
+A Cylc :term:`source directory` contains:
 
 :cylc:conf:`flow.cylc`
    The file which configures the workflow.
@@ -38,9 +38,11 @@ A Cylc :term:`suite directory` contains:
    - Custom :ref:`job submission modules <CustomJobSubmissionMethods>`.
    - Custom :ref:`Jinja2 Filters<CustomJinja2Filters>`).
 
-Other files and folders may be placed in the :term:`suite directory` e.g.
+Other files and folders may be placed in the :term:`source directory` e.g.
 documentation, configuration files, etc.
 
+When the workflow is :ref:`installed <Installing-workflows>`, these
+directories and files will be copied over to the :term:`run directory`.
 
 .. _FlowConfigFile:
 

src/user-guide/writing-suites/jinja2.rst

@@ -233,7 +233,7 @@ Here's the result:
 
 .. code-block:: console
 
-   $ cylc get-suite-config -i [runtime][airs]directives SUITE
+   $ cylc config -i [runtime][airs]directives SUITE
    -I = ncpus=9
 
 

src/user-guide/writing-suites/runtime.rst

@@ -107,13 +107,12 @@ multiple inheritance:
 .. literalinclude:: ../../suites/inherit/multi/one/flow.cylc
    :language: cylc
 
-``cylc get-suite-config`` provides an easy way to check the result of
+``cylc config`` provides an easy way to check the result of
 inheritance in a suite. You can extract specific items, e.g.:
 
 .. code-block:: console
 
-   $ cylc get-suite-config --item '[runtime][var_p2]script' \
-       inherit.multi.one
+   $ cylc config --item '[runtime][var_p2]script' inherit.multi.one
    echo "RUN: run-var.sh"
 
 or use the ``--sparse`` option to print entire namespaces
@@ -122,7 +121,7 @@ from the root namespace:
 
 .. code-block:: console
 
-   $ cylc get-suite-config --sparse --item '[runtime]ops_s1' inherit.multi.one
+   $ cylc config --sparse --item '[runtime]ops_s1' inherit.multi.one
    script = echo "RUN: run-ops.sh"
    inherit = ['OPS', 'SERIAL']
    [directives]
@@ -369,12 +368,12 @@ on the task host. Thus ``$HOME``, for instance, evaluates at
 run time to the home directory of task owner on the task host.
 
 
-How Tasks Get Access To The Suite Directory
--------------------------------------------
+How Tasks Get Access To The Run Directory
+-----------------------------------------
 
 The workflow bin directory is automatically added
 ``$PATH``. If a remote suite configuration directory is not
-specified the local (suite host) path will be assumed with the local
+specified, the local (suite host) path will be assumed with the local
 home directory, if present, swapped for literal ``$HOME`` for
 evaluation on the task host.