update code-block types for highlighting

Author: gonuke

source/arche/cli.rst

@@ -13,7 +13,7 @@ single-string form ``spec`` (e.g. ``:cycamore:Source``) which is discussed
 To view the auto-generated XML schema used for validating archetype
 configuration parameters in input files:
 
-  .. code-block:: bash
+  .. code-block:: console
 
       $ cyclus --agent-schema :agents:Source
       <interleave>
@@ -33,7 +33,7 @@ configuration parameters in input files:
 To view a JSON structured output of all the data generated and collected from
 ``#pragma cyclus`` annotations for a particular archetype:
 
-  .. code-block:: bash
+  .. code-block:: console
 
       $ cyclus --agent-annotations :cycamore:Source
       {
@@ -52,7 +52,7 @@ To view a JSON structured output of all the data generated and collected from
 
 And to list all archetypes inside a particular library:
 
-  .. code-block:: bash
+  .. code-block:: console
 
       $ cyclus --agent-listing :cycamore
       :cycamore:DeployInst
@@ -71,7 +71,7 @@ Archetype Versioning
 The ``cyclus::Agent`` class exposes a ``version()`` member function which can be
 queried with the |Cyclus| CLI. For example,
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cyclus --agent-version :agents:Source
     1.3.1-7-g9a2c9c9
@@ -94,7 +94,7 @@ your own version tag information for some archetype like
 
 and then access the version with
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cyclus --agent-version my/path:my_library:MyArchetype
     My Version

source/arche/cmake.rst

@@ -67,7 +67,7 @@ The ``UseCyclus.cmake`` macro suite uses the following terms:
   ``$CYCLUS_INSTALL_PREFIX/lib/cyclus/my_module_dir/``. The value of
   ``$CYCLUS_INSTALL_PREFIX`` can be queried by
 
-  .. code-block:: bash
+  .. code-block:: console
 
       $ cyclus --install-path
 

source/arche/errors.rst

@@ -132,7 +132,7 @@ suppress all warnings and a very large number will print them all.  For
 example, if the user wished to print the first 42 warnings of each kind they
 would call |cyclus| as follows:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cyclus --warn-limit 42 ...
 
@@ -142,7 +142,7 @@ and throws the error.  This is useful for ensuring that only stable code is
 executed or to help uncover what is causing a warning to be thrown.  It takes
 no arguments:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cyclus --warn-as-error ...
 

source/arche/hello_world_cpp.rst

@@ -14,7 +14,7 @@ available wherever ``cyclus`` is available.
 To use ``cycstub`` to generate the skeleton for a new Facility archetype named ``TutorialFacility`` in
 a module named ``TutorialLibrary`` you can issue the following command:
 
-.. code-block:: bash
+.. code-block:: console
 
     tutorial $ cycstub --type facility tutorial:TutorialLibrary:TutorialFacility
 
@@ -24,7 +24,7 @@ will not do anything, but will be a valid archetype for use in a simulation.
 
 You can add additional agents to this module by calling `cycstub` multiple times:
 
-.. code-block:: bash
+.. code-block:: console
 
     tutorial $ cycstub --type inst tutorial:TutorialLibrary:TutorialInstitution
     tutorial $ cycstub --type region tutorial:TutorialLibrary:TutorialRegion
@@ -60,7 +60,7 @@ install the ``tutorial`` project.  This done with the install.py script.
 The install script puts the project into your cyclus userspace,
 ``${HOME}/.local/lib/cyclus``.
 
-.. code-block:: bash
+.. code-block:: console
 
     tutorial $ python3 install.py
 
@@ -70,7 +70,7 @@ Let's run |cyclus| with the TutorialFacility! In the input directory there is
 an :file:`example_tutorial_facility.xml`. Running |cyclus| on this file with the command
 ``cyclus example_tutorial_facility.xml`` should produce the following output.
 
-.. code-block:: bash
+.. code-block:: console
 
     tutorial $ cyclus example_tutorial_facility.xml
                   :

source/arche/hello_world_py.rst

@@ -71,7 +71,7 @@ an :file:`example.xml`. First modify it to point to the archetype we just wrote.
 Running |cyclus| on this file with the command
 ``cyclus input/example.xml`` should produce the following output.
 
-.. code-block:: bash
+.. code-block:: console
 
     tutorial $ cyclus input/example.xml
                   :

source/arche/logger.rst

@@ -3,7 +3,7 @@
 Logging
 =======================
 
-.. code-block:: bash
+.. code-block:: console
 
   LOG(LogLevel level, std::string prefix)
 

source/arche/testing.rst

@@ -174,7 +174,7 @@ haven't already, now is a good time to add the ``$CYCLUS_INSTALL_PATH`` to your
 ``~/.local``). Next, from your top level directory (where your ``install.py``
 file is), run: 
 
-.. code-block:: bash
+.. code-block:: console
 
   $ ./install.py
   $ TickTracker_unit_tests
@@ -322,7 +322,7 @@ This will prevent exceptions from being caught resulting in a core-dump.  You
 can then use a debugger (e.g. gdb or lldb) to run the failing simulation and
 investigate the source of the crash in more detail.  Something like this:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ CYCLUS_NO_CATCH=1 gdb --args cyclus my-failing-sim.xml
     
@@ -339,7 +339,7 @@ with respect to resource exchange.  To turn on this debugging, simply run
 cyclus with the environment variable ``CYCLUS_DEBUG_DRE`` set to any non-empty
 value:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ CYCLUS_DEBUG_DRE=1 cyclus my-sim.xml
 

source/arche/tour_cpp.rst

@@ -8,7 +8,7 @@ This section will walk through the source files of the stub :term:`archetypes
 can generate stubs for each of the agent types.  The standard usage to generate the 
 stubs for a Facility, Institution or Region, respectively, is:
 
-.. code-block:: bash
+.. code-block:: console
 
   cycstub --type facility :stublibrary:StubFacility
   cycstub --type institution :stublibrary:StubInstitution

source/cep/cep3.rst

@@ -142,7 +142,7 @@ Release Process
 
     - make sure to have your ``rs.cred`` file (see ``maintenance.sh``'s help)
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/release/utils
       $ export CYCLUS_DIR=/path/to/cyclus
@@ -163,7 +163,7 @@ Release Process
           #. if the dev-list agrees to those changes, update the symbols and
              commit the new one:
 
-          .. code-block:: bash
+          .. code-block:: console
 
                 $ cd $CYCLUS_DIR/release
                 $ ./smbchk.py --update -t X.X.X # X.X.X is *this* version
@@ -173,15 +173,15 @@ Release Process
 
 #. Commit all changes for all projects.
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/project
       $ git checkout vX.X.X-release
       $ git commit -am "final release commit after maintenence"
 
 #. Update all master branches.
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/project
       $ git checkout master
@@ -190,7 +190,7 @@ Release Process
 
 #. *Locally* tag the repository for *each* of the projects.
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/project
       $ git checkout master
@@ -202,7 +202,7 @@ Release Process
     - the ``make_release_notes.sh`` utility in ``release/utils`` will help
       provide a template
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/release/utils
       $ export CYCLUS_DIR=/path/to/cyclus
@@ -218,7 +218,7 @@ Release Process
     - the ``api_docs.sh`` utility in ``release/utils`` will do this
       automatically for you
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/release/utils
       $ export CYCLUS_DIR=/path/to/cyclus
@@ -227,7 +227,7 @@ Release Process
 
 #. Update the ``master`` branch of all projects and clean up.
 
-    .. code-block:: bash
+    .. code-block:: console
 
       $ cd /path/to/project
       $ git push upstream X.X.X master
@@ -293,7 +293,7 @@ Release Process
    have to be compiled on you system and both executable and lib have to be on
    the default paths. Please refer to the :doc:`source installation
    <../user/install_from_git>` if you need.
-.. .. code-block:: bash
+.. .. code-block:: console
       $ git clone https://github.com/rwcarlsen/cloudlus.git
       $ cd cloudlus
       $ go install ./cmd/cloudlus
@@ -327,7 +327,7 @@ evolves, we'll want to have our version evolve as well. Here are the steps to do
 These assume that in your HOME dir there are both the pyne and |cyclus| repos.  Remember
 to check in the changes afterwards.
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cd ~/pyne
     $ ./amalgamate.py -s pyne.cc -i pyne.h
@@ -337,7 +337,7 @@ to check in the changes afterwards.
 our source data.  Occassionally, this needs to be updated as updates to pyne itself come out.
 The command for generating |cyclus| specific nuclear data is as follows:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ cd ~/pyne
    $ nuc_data_make -o cyclus_nuc_data.h5 \
@@ -357,7 +357,7 @@ automatically.  In order to check this correctly, you must have a **RELEASE**
 build of Cyclus compiled/installed.  Every release please run the following
 command to verify that the release branch is stable:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cd cyclus/release
     $ ./smbchk.py --update -t HEAD --no-save --check
@@ -374,7 +374,7 @@ Once stable and there are no more code changes to be made, add the symbols
 in this release to the database with the following command (again - make sure
 you are working on a RELEASE build of Cyclus):
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cd cyclus/release
     $ ./smbchk.py --update -t X.X.X

source/user/cymetric/tutorial_cli.rst

@@ -28,7 +28,7 @@ Since cymetric is wholly dependent on |cyclus| databases, you must supply a
 database as an argument on the command line. This will look something like the
 following:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric database -flags
 
@@ -46,7 +46,7 @@ database.  Note that this may list more tables in the database than are
 strictly part of the |cyclus| interface, because of the need for |cyclus| to
 store metadata. Don't be alarmed. Listing the current tables is easy:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 -l
     AgentEntry
@@ -90,7 +90,7 @@ can use. Indexing the table variables will return the metric as a `pandas
 ``AgentEntry`` table, we would write ``AgentEntry[:]`` to get the table and
 ``print(AgentEntry[:])`` to display it after the ``-e`` flag:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 -e "print(AgentEntry[:])"
                                       SimId  AgentId      Kind                    Spec          Prototype  ParentId  Lifetime  EnterTime
@@ -109,7 +109,7 @@ Indexing a metric with an empty slice (``[:]``), none (``[None]``), or an ellips
 filters on the column names. The column names of the metric are thus also available for
 use.  For example, let's just grab all of the facilities out of the entry table:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 -e "print(AgentEntry[Kind == 'Facility'])"
                                       SimId  AgentId      Kind                    Spec   Prototype  ParentId  Lifetime  EnterTime
@@ -124,7 +124,7 @@ use.  For example, let's just grab all of the facilities out of the entry table:
 Separate the conditions by commas (``,``) to apply multiple filters at the same
 time:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 -e "print(AgentEntry[Kind == 'Facility', AgentId > 14])"
                                       SimId  AgentId      Kind                    Spec Prototype  ParentId  Lifetime  EnterTime
@@ -139,7 +139,7 @@ able to do in Python. Suppose that we have a ``Materials`` metric with a ``Mass`
 column. We can compute this metric, pull the column out, multiply it by 42,
 save the result to a variable, and then print this variable all via the following.
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 -e "mass = Materials[:]['Mass'] * 42; print(mass)"
     0      0.000000
@@ -192,7 +192,7 @@ Module                Alias
 This let's you do neat things such as plot the metrics right from the command line.
 For example,
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 -e "Materials[ResourceId == 15].plot(x='NucId', y='Mass', kind='bar'); plt.show()"
 
@@ -210,15 +210,15 @@ default functionality when you use the ``-e`` flag, the lack of writing
 can be accomplished with the ``--no-write`` flag. In the example below, the
 table will not be written to the database:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 --no-write -e "Materials[:]"
 
 Since cymetric looks up an already evaluated metric in the database,
 overwriting an existing table with a new one might be desired. This is where
 the ``--write`` flag is useful:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cymetric test.h5 --write -e "Materials[:]"