Start checking rst files at pre-commit level with rstcheck

Additionally, fixed most of the errors reported by rstcheck.

Fixes https://github.com/saltstack/salt/issues/58668

.pre-commit-config.yaml

@@ -1112,6 +1112,16 @@ repos:
                 tests/kitchen/.*
             )$
 
+  - repo: https://github.com/myint/rstcheck
+    # This, for now, is meant to run when locally committing code and will be disabled(skipped) when we run pre-commit
+    # against all codebase to avoid MASSIVE code churn. This way, we do it in smaller chunks, a few at a time.
+    rev: 3f92957
+    hooks:
+      - id: rstcheck
+        name: Check reST files using rstcheck
+        args: [--report=warning]
+        additional_dependencies: [sphinx]
+
   - repo: https://github.com/asottile/blacken-docs
     rev: v1.7.0
     hooks:

.rstcheck.cfg

@@ -0,0 +1,27 @@
+[rstcheck]
+ignore_directives=
+  automodule,
+  autoclass,
+  autofunction,
+  conf_proxy,
+  conf_log,
+  conf_master,
+  conf_minion,
+  releasestree,
+  jinja_ref,
+  salt:event
+ignore_roles=
+  conf_master,
+  conf_minion,
+  conf_proxy,
+  conf_log,
+  formula_url,
+  issue,
+  pull,
+  blob,
+  jinja_ref
+ignore_substitutions=
+  saltrepo,
+  repo_primary_branch,
+  windownload,
+  osxdownloadpy3

cicd/jenkins/pre-commit

@@ -5,7 +5,7 @@ if (env.CHANGE_ID) {
     pre_commit_skips = ''
 } else {
     // This is a branch build
-    pre_commit_skips = 'pyupgrade,remove-import-headers'
+    pre_commit_skips = 'pyupgrade,remove-import-headers,rstcheck'
 }
 
 runPreCommit(

doc/ref/configuration/master.rst

@@ -2022,7 +2022,7 @@ Each minion connecting to the master uses AT LEAST one file descriptor, the
 master subscription connection. If enough minions connect you might start
 seeing on the console(and then salt-master crashes):
 
-.. code-block:: bash
+.. code-block:: text
 
     Too many open files (tcp_listener.cpp:335)
     Aborted (core dumped)

doc/ref/modules/index.rst

@@ -97,7 +97,7 @@ included libraries.
 
 Then, create the zip:
 
-.. code-block:: bash
+.. code-block:: console
 
     modules $ zip -r lumberjack lumberjack
       adding: lumberjack/ (stored 0%)

doc/ref/runners/index.rst

@@ -125,4 +125,4 @@ responding to Salt calls could look like this:
         client = salt.client.LocalClient(__opts__["conf_file"])
         minions = client.cmd("*", "test.version", timeout=1)
         for minion in sorted(minions):
-            print minion
+            print(minion)

doc/ref/states/requisites.rst

@@ -363,6 +363,8 @@ shown in json for clarity:
         }
     }
 
+.. code-block:: json
+
     {
         "local": {
             "pkgrepo_|-salt-minion_|-salt-minion_|-managed": {

doc/ref/states/writing.rst

@@ -66,6 +66,7 @@ A well-written state function will follow these steps:
 
    .. code-block:: python
 
+       def myfunc():
            ret = {"name": name, "result": False, "changes": {}, "comment": ""}
 
            if foo and bar:
@@ -87,6 +88,7 @@ A well-written state function will follow these steps:
 
    .. code-block:: python
 
+       def myfunc():
            if result:
                ret["result"] = True
                ret["comment"] = "{0} is already installed".format(name)
@@ -99,6 +101,7 @@ A well-written state function will follow these steps:
 
    .. code-block:: python
 
+       def myfunc():
            if __opts__["test"]:
                ret["result"] = None
                ret["comment"] = "{0} would be installed".format(name)
@@ -132,6 +135,7 @@ A well-written state function will follow these steps:
 
    .. code-block:: python
 
+       def myfunc():
            if ret["changes"]:
                ret["comment"] = "{0} failed to install".format(name)
            else:
@@ -307,6 +311,7 @@ run. An example of such a check could look like this:
 
 .. code-block:: python
 
+    def myfunc():
         # Return comment of changes if test.
         if __opts__["test"]:
             ret["result"] = None

doc/topics/cloud/aws.rst

@@ -949,7 +949,7 @@ Alternate Endpoint
 Normally, EC2 endpoints are build using the region and the service_url. The
 resulting endpoint would follow this pattern:
 
-.. code-block:: bash
+.. code-block:: text
 
     ec2.<region>.<service_url>
 

doc/topics/cloud/cloudstack.rst

@@ -119,7 +119,7 @@ command:
 Images can be obtained using the ``--list-images`` option for the ``salt-cloud``
 command:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-cloud --list-images exoscale
     exoscale:

doc/topics/cloud/config.rst

@@ -652,6 +652,7 @@ data:
 
 .. code-block:: python
 
+    {
         "providers": {
             "my-develop-envs": [
                 {
@@ -685,3 +686,4 @@ data:
                 }
             ],
         }
+    }

doc/topics/cloud/dimensiondata.rst

@@ -74,7 +74,7 @@ command --list-sizes is run a default will be returned).
 Images can be obtained using the ``--list-images`` option for the ``salt-cloud``
 command:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-cloud --list-images my-dimensiondata-config
     my-dimensiondata-config:

doc/topics/cloud/gogrid.rst

@@ -89,7 +89,7 @@ command:
 Images can be obtained using the ``--list-images`` option for the ``salt-cloud``
 command:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-cloud --list-images my-gogrid-config
     my-gogrid-config:

doc/topics/cloud/joyent.rst

@@ -93,7 +93,7 @@ command:
 Images can be obtained using the ``--list-images`` option for the ``salt-cloud``
 command:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-cloud --list-images my-joyent-config
     my-joyent-config:

doc/topics/cloud/qs.rst

@@ -67,7 +67,7 @@ List Cloud Provider Options
 You can now query the cloud provider you configured for available locations,
 images, and sizes. This information is used when you set up VM profiles.
 
-.. code-block:: bash
+.. code-block:: console
 
     salt-cloud --list-locations <provider_name>  # my-ec2 in the previous example
     salt-cloud --list-images <provider_name>
@@ -109,7 +109,7 @@ Create VMs
 ----------
 VMs are created by calling ``salt-cloud`` with the following options:
 
-.. code-block:: bash
+.. code-block:: console
 
     salt-cloud -p <profile> <name1> <name2> ...
 

doc/topics/cloud/scaleway.rst

@@ -47,7 +47,7 @@ Set up an initial profile at /etc/salt/cloud.profiles or in the /etc/salt/cloud.
 
 Images can be obtained using the ``--list-images`` option for the ``salt-cloud`` command:
 
-.. code-block:: bash
+.. code-block:: console
 
     #salt-cloud --list-images my-scaleway-config
     my-scaleway-config:
@@ -81,7 +81,7 @@ Images can be obtained using the ``--list-images`` option for the ``salt-cloud``
 
 Execute a query and return all information about the nodes running on configured cloud providers using the ``-Q`` option for the ``salt-cloud`` command:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-cloud -F
     [INFO    ] salt-cloud starting

doc/topics/cloud/troubleshooting.rst

@@ -122,7 +122,7 @@ following command:
 The if the output of this command includes a line that looks like this, then
 the ``/tmp/`` directory is mounted as ``noexec``:
 
-.. code-block:: bash
+.. code-block:: console
 
     tmpfs on /tmp type tmpfs (rw,noexec)
 

doc/topics/cloud/vagrant.rst

@@ -243,7 +243,7 @@ Create and use your new Salt minion
 
 .. _this gist: https://github.com/jirsbek/SSH-keys-in-macOS-Sierra-keychain
 
-.. code-block:: bash
+.. code-block:: console
 
     ssh -A vagrant@< the bridged network address >
       # [ or, if you are at /home/my_username/ on my_laptop ]
@@ -251,7 +251,7 @@ Create and use your new Salt minion
 
 - then typing on your new node "v1" (a.k.a. quail1.bevy1.test)...
 
-.. code-block:: bash
+.. code-block:: console
 
     password: vagrant
       # [ stuff types out ... ]

doc/topics/development/hacking.rst

@@ -172,7 +172,7 @@ If you would like to log to the console instead of to the log file, remove the
 
     Once the minion starts, you may see an error like the following:
 
-    .. code-block:: bash
+    .. code-block:: console
 
         zmq.core.error.ZMQError: ipc path "/path/to/your/virtualenv/
         var/run/salt/minion/minion_event_7824dcbcfd7a8f6755939af70b96249f_pub.ipc"

doc/topics/development/package_providers.rst

@@ -82,6 +82,7 @@ Deprecated and destined to be removed. For now, should just do the following:
 
 .. code-block:: python
 
+    def myfunc():
         return __salt__["pkg.latest_version"](name) != ""
 
 
@@ -138,6 +139,7 @@ return the output of ``salt.utils.data.compare_dicts()``:
 
 .. code-block:: python
 
+    def myfunc():
         return salt.utils.data.compare_dicts(old, new)
 
 
@@ -174,7 +176,7 @@ Lists the repositories that are currently configured on this system.
 
 Returns a dictionary, in the following format:
 
-.. code-block:: python
+.. code-block:: pycon
 
     {'reponame': 'config_key_1': 'config value 1',
                  'config_key_2': 'config value 2',
@@ -192,7 +194,7 @@ Displays all local configuration for a specific repository.
 The information is formatted in much the same way as list_repos, but is
 specific to only one repo.
 
-.. code-block:: python
+.. code-block:: pycon
 
     {'config_key_1': 'config value 1',
      'config_key_2': 'config value 2',

doc/topics/development/tests/integration.rst

@@ -347,18 +347,19 @@ Testing salt-ssh functionality can be done using the SSHCase test class:
 
     from tests.support.case import SSHCase
 
+
     class SSHGrainsTest(SSHCase):
-    '''
+        """
         Test salt-ssh grains functionality
         Depend on proper environment set by integration.SSHCase class
-    '''
+        """
 
         def test_grains_id(self):
-        '''
+            """
             Test salt-ssh grains id work for localhost.
-        '''
-        cmd = self.run_function('grains.get', ['id'])
-        self.assertEqual(cmd, 'localhost')
+            """
+            cmd = self.run_function("grains.get", ["id"])
+            self.assertEqual(cmd, "localhost")
 
 
 Testing Event System via SaltMinionEventAssertsMixin
@@ -582,40 +583,39 @@ contain valid information are also required in the test class's ``setUp`` functi
     from tests.support.case import ShellCase
     from tests.support.paths import FILES
 
+
     class LinodeTest(ShellCase):
-    '''
+        """
         Integration tests for the Linode cloud provider in Salt-Cloud
-    '''
+        """
 
         def setUp(self):
-        '''
+            """
             Sets up the test requirements
-        '''
+            """
             super(LinodeTest, self).setUp()
 
             # check if appropriate cloud provider and profile files are present
-        profile_str = 'linode-config:'
-        provider = 'linode'
-        providers = self.run_cloud('--list-providers')
+            profile_str = "linode-config:"
+            provider = "linode"
+            providers = self.run_cloud("--list-providers")
             if profile_str not in providers:
                 self.skipTest(
-                'Configuration file for {0} was not found. Check {0}.conf files '
-                'in tests/integration/files/conf/cloud.*.d/ to run these tests.'
-                .format(provider)
+                    "Configuration file for {0} was not found. Check {0}.conf files "
+                    "in tests/integration/files/conf/cloud.*.d/ to run these tests.".format(
+                        provider
+                    )
                 )
 
             # check if apikey and password are present
-        path = os.path.join(FILES,
-                            'conf',
-                            'cloud.providers.d',
-                            provider + '.conf')
+            path = os.path.join(FILES, "conf", "cloud.providers.d", provider + ".conf")
             config = cloud_providers_config(path)
-        api = config['linode-config']['linode']['apikey']
-        password = config['linode-config']['linode']['password']
-        if api == '' or password == '':
+            api = config["linode-config"]["linode"]["apikey"]
+            password = config["linode-config"]["linode"]["password"]
+            if api == "" or password == "":
                 self.skipTest(
-                'An api key and password must be provided to run these tests. Check '
-                'tests/integration/files/conf/cloud.providers.d/{0}.conf'.format(
+                    "An api key and password must be provided to run these tests. Check "
+                    "tests/integration/files/conf/cloud.providers.d/{0}.conf".format(
                         provider
                     )
                 )

doc/topics/development/tutorial.rst

@@ -146,7 +146,7 @@ Push
 Push your branch to your GitHub account.  You will likely need to enter your
 GitHub username and password.
 
-.. code-block:: bash
+.. code-block:: console
 
     $ git push origin virt_ret
     Username for 'https://github.com': <my_account>
@@ -159,7 +159,7 @@ GitHub username and password.
     you have done this, you may need add the keys to your git repository
     configuration
 
-    .. code-block:: bash
+    .. code-block:: console
 
         $ git config ssh.key ~/.ssh/<key_name>
 

doc/topics/event/events.rst

@@ -247,10 +247,9 @@ done at the CLI:
 
     caller = salt.client.Caller()
 
-    ret = caller.cmd('event.send',
-                     'myco/event/success'
-                     { 'success': True,
-                       'message': "It works!" })
+    ret = caller.cmd(
+        "event.send", "myco/event/success", {"success": True, "message": "It works!"}
+    )
 
     if not ret:
         # the event could not be sent, process the error here

doc/topics/grains/index.rst

@@ -217,7 +217,7 @@ grain data structure. For example, consider this custom grain file:
 
 The output of this example renders like so:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-call --local grains.items
     local:
@@ -235,7 +235,7 @@ the function will be rendered twice by Salt in the items output: once for the
 ``my_custom_grain`` call itself, and again when it is called in the ``main``
 function:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-call --local grains.items
     local:

doc/topics/installation/eos.rst

@@ -57,7 +57,7 @@ Change the Salt master IP address or FQDN, by edit the variable (SALT_MASTER)
 
 Make sure you enable the eAPI with unix-socket
 
-.. code-block:: bash
+.. code-block:: console
 
     veos(config)#management api http-commands
              protocol unix-socket
@@ -83,7 +83,7 @@ Copy the installed extensions to boot-extensions
 
 Apply event-handler to let EOS start salt-minion during boot-up
 
-.. code-block:: bash
+.. code-block:: console
 
    veos(config)#event-handler boot-up-script
       trigger on-boot
@@ -112,7 +112,7 @@ If you decide to uninstall this package, the following steps are recommended for
 
 2. Remove boot-up script
 
-.. code-block:: bash
+.. code-block:: console
 
    veos(config)#no event-handler boot-up-script
 

doc/topics/installation/nxos.rst

@@ -165,7 +165,7 @@ Starting in release ``9.2(1)`` and onward, the .ova file can be copied to the ``
 
 Copy the ``guestshell.ova`` file to ``volatile:`` if supported, otherwise copy it to ``bootflash:``
 
-.. code:: bash
+.. code-block:: console
 
   n3xxx# copy scp://admin@1.2.3.4/guestshell.ova volatile: vrf management
   guestshell.ova 100% 55MB 10.9MB/s 00:05
@@ -174,7 +174,7 @@ Copy the ``guestshell.ova`` file to ``volatile:`` if supported, otherwise copy i
 
 Use the ``guestshell enable`` command to install and enable guestshell.
 
-.. code:: bash
+.. code-block:: console
 
   n3xxx# guestshell enable package volatile:guestshell.ova
 
@@ -213,7 +213,7 @@ The ``guestshell`` container environment is enabled by default on most platforms
 
 **Example.** Allocate resources for guestshell by setting new limits to 500MB disk and 350MB memory.
 
-.. code:: bash
+.. code:: console
 
   n3k# guestshell resize rootfs 500
   n3k# guestshell resize memory 350
@@ -238,7 +238,7 @@ The ``guestshell`` is an independent CentOS container that does not inherit sett
 
 **OPTIONAL: Add DNS Configuration**
 
-.. code:: bash
+.. code:: console
 
   [root@guestshell guestshell]#  cat >> /etc/resolv.conf << EOF
   nameserver 10.0.0.202
@@ -248,7 +248,7 @@ The ``guestshell`` is an independent CentOS container that does not inherit sett
 
 **OPTIONAL: Define proxy server variables if needed to allow network access to SaltStack package repositories**
 
-.. code:: bash
+.. code:: console
 
   export http_proxy=http://proxy.yourdomain.com:<port>
   export https_proxy=https://proxy.yourdomain.com:<port>

doc/topics/jinja/index.rst

@@ -1348,7 +1348,7 @@ Example:
 
 Returns:
 
-.. code-block:: python
+.. code-block:: pycon
 
   {
     'body': '{
@@ -2205,7 +2205,7 @@ log at the ``profile`` level along with the render time of the block.
 The ``profile`` block in the ``example.sls`` state will emit the following log
 statement:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-call --local -l profile state.apply example
     [...]
@@ -2241,7 +2241,7 @@ Using the same logic as the ``profile`` block, the ``import_yaml``,
 
 For ``import_*`` blocks, the ``profile`` log statement has the following form:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt-call --local -l profile state.apply example
     [...]

doc/topics/releases/2016.11.0.rst

@@ -240,7 +240,7 @@ Grains Changes
 
   New behavior:
 
-  .. code-block:: bash
+  .. code-block:: console
 
       root@master:~# salt 'testwin200' grains.item cpu_model
       testwin200:

doc/topics/releases/2019.2.0.rst

@@ -713,7 +713,7 @@ Alternatively, the newly-added :py:func:`pkg.show <salt.modules.aptpkg.show>`
 function can be used to get more detailed information about a given package and
 help determine what package name is correct:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt myminion pkg.show 'nginx*' filter=description,provides
     myminion:
@@ -955,7 +955,7 @@ Those who are using the :ref:`LocalClient <local-client>` (either directly,
 or implicitly via a :ref:`netapi module <all-netapi-modules>`) need to update
 their code to use ``tgt_type``.
 
-.. code-block:: python
+.. code-block:: pycon
 
     >>> import salt.client
     >>> local = salt.client.LocalClient()

doc/topics/releases/3000.rst

@@ -292,7 +292,7 @@ A new :py:func:`state <salt.states.keystore>` and
 Keystore files is now included. It allows for adding/removing/listing
 as well as managing keystore files.
 
-.. code-block:: bash
+.. code-block:: console
 
   # salt-call keystore.list /path/to/keystore.jks changeit
   local:

doc/topics/releases/releasecandidate.rst

@@ -115,7 +115,7 @@ Then install salt using the following command:
 
 .. code-block:: bash
 
-    sudo pip install salt==<rc tag version>
+    sudo pip install salt==$rc_tag_version
 
 For example for the 3002rc1 release:
 

doc/topics/spm/dev.rst

@@ -41,6 +41,7 @@ connection object, then that connection object is returned. For instance, the
 
 .. code-block:: python
 
+   def myfunc():
        conn = sqlite3.connect(__opts__["spm_db"], isolation_level=None)
        ...
        return conn

doc/topics/troubleshooting/index.rst

@@ -112,7 +112,7 @@ The salt-master needs at least 2 sockets per host that connects to it, one for
 the Publisher and one for response port. Thus, large installations may, upon
 scaling up the number of minions accessing a given master, encounter:
 
-.. code-block:: bash
+.. code-block:: console
 
     12:45:29,289 [salt.master    ][INFO    ] Starting Salt worker process 38
     Too many open files

doc/topics/troubleshooting/master.rst

@@ -47,7 +47,7 @@ The salt-master needs at least 2 sockets per host that connects to it, one for
 the Publisher and one for response port. Thus, large installations may, upon
 scaling up the number of minions accessing a given master, encounter:
 
-.. code-block:: bash
+.. code-block:: console
 
     12:45:29,289 [salt.master    ][INFO    ] Starting Salt worker process 38
     Too many open files
@@ -188,7 +188,7 @@ profiling graphs could use `gprof2dot`_, `graphviz`_ and this batch file:
 .. _`gprof2dot`: https://pypi.org/project/gprof2dot
 .. _`graphviz`: https://graphviz.gitlab.io
 
-.. code-block:: bash
+.. code-block:: batch
 
     ::
     :: Converts callgrind* profiler output to *.pdf, via *.dot

doc/topics/troubleshooting/minion.rst

@@ -35,7 +35,7 @@ on various platforms.
 If you have netcat installed, you can check port connectivity from the minion
 with the ``nc`` command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ nc -v -z salt.master.ip.addr 4505
     Connection to salt.master.ip.addr 4505 port [tcp/unknown] succeeded!
@@ -44,7 +44,7 @@ with the ``nc`` command:
 
 The `Nmap`_ utility can also be used to check if these ports are open:
 
-.. code-block:: bash
+.. code-block:: console
 
     # nmap -sS -q -p 4505-4506 salt.master.ip.addr
 

doc/topics/tutorials/cloud_controller.rst

@@ -342,7 +342,7 @@ to the minions to refresh the pillar to pick up on the change:
 Now, migration routines can be run! To migrate a VM, simply run the Salt Virt
 migrate routine:
 
-.. code-block:: bash
+.. code-block:: console
 
     salt-run virt.migrate centos <new hypervisor>
 

doc/topics/tutorials/gitfs.rst

@@ -1012,7 +1012,7 @@ host key in the ``~/.ssh/known_hosts`` file. If the master is also a minion,
 this can be done using the :mod:`ssh.set_known_host
 <salt.modules.ssh.set_known_host>` function:
 
-.. code-block:: bash
+.. code-block:: console
 
     # salt mymaster ssh.set_known_host user=root hostname=github.com
     mymaster:
@@ -1056,7 +1056,7 @@ Verifying the Fingerprint
 To verify that the correct fingerprint was added, it is a good idea to look it
 up. One way to do this is to use ``nmap``:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ nmap -p 22 github.com --script ssh-hostkey
 
@@ -1138,7 +1138,7 @@ steps to this process:
    all users to fire the event.  Add the following policy to the sudoers file
    on the git server.
 
-   .. code-block:: bash
+   .. code-block:: console
 
        Cmnd_Alias SALT_GIT_HOOK = /bin/salt-call event.fire_master update salt/fileserver/gitfs/update
        Defaults!SALT_GIT_HOOK !requiretty

doc/topics/tutorials/http.rst

@@ -469,6 +469,7 @@ value of match in the return text. In Python terms this looks like:
 
 .. code-block:: python
 
+   def myfunc():
        if match in html_text:
            return True
 

doc/topics/tutorials/intro_scale.rst

@@ -144,7 +144,7 @@ be doubled after each attempt to reconnect (ZeroMQ default behavior).
 
 Lets say the generated random value is 11 seconds (or 11000ms).
 
-.. code-block:: bash
+.. code-block:: console
 
     reconnect 1: wait 11 seconds
     reconnect 2: wait 22 seconds

doc/topics/tutorials/libcloud.rst

@@ -98,7 +98,7 @@ The module documentation explains each of the API methods and how to leverage th
 
 For example, listing buckets in the Google Storage platform:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ salt-call libcloud_storage.list_containers google
 

doc/topics/tutorials/packaging_modules.rst

@@ -25,11 +25,11 @@ function:
     from setuptools import setup, find_packages
 
     setup(
-        name=<NAME>,
-        version=<VERSION>,
-        description=<DESC>,
-        author=<AUTHOR>,
-        author_email=<AUTHOR-EMAIL>,
+        name=THE_NAME,
+        version=THE_VERSION,
+        description=THE_DESCRIPTION,
+        author=THE_AUTHOR_NAME,
+        author_email=THE_AUTHOR_EMAIL,
         url=" ... ",
         packages=find_packages(),
         entry_points="""
@@ -39,7 +39,7 @@ function:
         pillar_dirs = <package>.<loader-module>:pillar_dirs
         returner_dirs = <package>.<loader-module>:returner_dirs
         roster_dirs = <package>.<loader-module>:roster_dirs
-        """
+        """,
     )
 
 
@@ -57,36 +57,36 @@ how `<package>/<loader-module>.py` it should look:
 
 
     def engines_dirs():
-	'''
+        """
         yield one path per parent directory of where engines can be found
-	'''
-	yield os.path.join(PKG_DIR, 'engines_1')
-	yield os.path.join(PKG_DIR, 'engines_2')
+        """
+        yield os.path.join(PKG_DIR, "engines_1")
+        yield os.path.join(PKG_DIR, "engines_2")
 
 
     def fileserver_dirs():
-	'''
+        """
         yield one path per parent directory of where fileserver modules can be found
-	'''
-	yield os.path.join(PKG_DIR, 'fileserver')
+        """
+        yield os.path.join(PKG_DIR, "fileserver")
 
 
     def pillar_dirs():
-	'''
+        """
         yield one path per parent directory of where external pillar modules can be found
-	'''
-	yield os.path.join(PKG_DIR, 'pillar')
+        """
+        yield os.path.join(PKG_DIR, "pillar")
 
 
     def returner_dirs():
-	'''
+        """
         yield one path per parent directory of where returner modules can be found
-	'''
-	yield os.path.join(PKG_DIR, 'returners')
+        """
+        yield os.path.join(PKG_DIR, "returners")
 
 
     def roster_dirs():
-	'''
+        """
         yield one path per parent directory of where roster modules can be found
-	'''
-	yield os.path.join(PKG_DIR, 'roster')
+        """
+        yield os.path.join(PKG_DIR, "roster")

doc/topics/windows/windows-package-manager.rst

@@ -493,7 +493,7 @@ You can get a list of packages installed on the system using
 This will return all software installed on the system whether it is managed by
 Salt or not as shown below:
 
-.. code-block:: bash
+.. code-block:: console
 
     local:
         ----------
@@ -647,7 +647,7 @@ be inside that directory and named ``init.sls``.
 Look at the following example directory structure on a Linux master assuming
 default config settings:
 
-.. code-block:: bash
+.. code-block:: console
 
     srv/
     |---salt/
@@ -932,7 +932,7 @@ the control panel. You can also get this information by installing the package
 manually and then running ``pkg.list_pkgs``. Here's an example of the output
 from ``pkg.list_pkgs``:
 
-.. code-block:: bash
+.. code-block:: console
 
     salt 'test-2008' pkg.list_pkgs
     test-2008