Normalize code blocks

- console lexer for anything that is a console session
- some other specialized lexers when it makes sense
- always with prompt, when in a console session, or for commands that
  are meant to be executed

Closes #1013

Author: mih

docs/basics/101-101-create.rst

@@ -27,7 +27,7 @@ and create a fresh, empty dataset with the :dlcmd:`create` command.
 
 Note the command structure of :dlcmd:`create` (optional bits are enclosed in ``[ ]``):
 
-.. code-block:: bash
+.. code-block::
 
   datalad create [--description "..."] [-c <config options>] PATH
 
@@ -39,9 +39,9 @@ Note the command structure of :dlcmd:`create` (optional bits are enclosed in ``[
    The optional ``--description`` flag allows you to provide a short description of
    the *location* of your dataset, for example with
 
-   .. code-block:: bash
+   .. code-block:: console
 
-      datalad create --description "course on DataLad-101 on my private laptop" -c text2git DataLad-101
+      $ datalad create --description "course on DataLad-101 on my private laptop" -c text2git DataLad-101
 
    If you want, use the above command instead of the :dlcmd:`create` command below
    to provide a description. Its use will not be immediately clear, the chapter

docs/basics/101-105-install.rst

@@ -121,18 +121,18 @@ chapters in this handbook will demonstrate how useful this information can be.
    point to root of the top-most dataset. For example, if you navigate into ``recordings``,
    the command would be:
 
-   .. code-block:: bash
+   .. code-block:: console
 
-     datalad clone -d^ https://github.com/datalad-datasets/longnow-podcasts.git longnow
+     $ datalad clone -d^ https://github.com/datalad-datasets/longnow-podcasts.git longnow
 
 .. find-out-more:: What if I do not install into an existing dataset?
 
    If you do not install into an existing dataset, you only need to omit the ``-d/--dataset``
    option. You can try:
 
-   .. code-block:: bash
+   .. code-block:: console
   
-     datalad clone https://github.com/datalad-datasets/longnow-podcasts.git
+     $ datalad clone https://github.com/datalad-datasets/longnow-podcasts.git
 
    anywhere outside of your ``DataLad-101`` dataset to install the podcast dataset into a new directory
    called ``longnow-podcasts``. You could even do this inside of an existing dataset.
@@ -266,7 +266,7 @@ Try to open it -- it will now work.
 If you would want to get the rest of the missing data, instead of specifying all files individually,
 we can use ``.`` to refer to *all* of the dataset like this:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ datalad get .
 

docs/basics/101-106-nesting.rst

@@ -110,7 +110,7 @@ we can set subdatasets to previous states, or *update* them.
    Thus, from the root of ``DataLad-101``, this command would have given you the
    subdataset's history as well:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ git -C recordings/longnow log --oneline
 

docs/basics/101-107-summary.rst

@@ -8,9 +8,9 @@ and making simple modifications *locally*.
   to the dataset and use the ``-c text2git`` configuration, but we will see later why.
   This is the command structure:
 
-  .. code-block:: bash
+  .. code-block:: console
 
-    datalad create --description "here is a description" -c text2git PATH
+    $ datalad create --description "here is a description" -c text2git PATH
 
 * Thanks to :term:`Git` and :term:`git-annex`, the dataset has a history to track files and their
   modifications. Built-in Git tools (:gitcmd:`log`) or external tools (such as ``tig``) allow to explore
@@ -23,9 +23,9 @@ and making simple modifications *locally*.
   specifying a path, all untracked files and all file changes will be committed to the history together!
   This is the command structure:
 
-  .. code-block:: bash
+  .. code-block:: console
 
-    datalad save -m "here is a commit message" [PATH]
+    $ datalad save -m "here is a commit message" [PATH]
 
 * The typical local workflow is simple: *Modify* the dataset by adding or
   modifying files, *save* the changes as meaningful units to the history,
@@ -53,7 +53,7 @@ and experienced the concept of modular nesting datasets.
 
 * A published dataset can be installed with the :dlcmd:`clone` command:
 
-  .. code-block:: bash
+  .. code-block:: console
 
      $ datalad clone [--dataset PATH] SOURCE-PATH/URL [DESTINATION PATH]
 

docs/basics/101-109-rerun.rst

@@ -77,9 +77,9 @@ We can use the shorthand "BF" to denote "Bug fix" in the commit message.
 What we *could* do is run the same :dlcmd:`run` command as before to recreate
 the file, but now with all of the contents:
 
-.. code-block:: bash
+.. code-block:: console
 
-   # do not execute this!
+   $ # do not execute this!
    $ datalad run -m "create a list of podcast titles" \
      "bash code/list_titles.sh > recordings/podcasts.tsv"
 

docs/basics/101-110-run2.rst

@@ -154,9 +154,9 @@ specifying inputs even though they are already present will not do any harm.
    Often, a command needs several inputs. In principle, every input (which could be files, directories, or subdatasets) gets its own ``-i``/``--input``
    flag. However, you can make use of :term:`globbing`. For example,
 
-   .. code-block:: bash
+   .. code-block:: console
 
-      datalad run --input "*.jpg" "COMMAND"
+      $ datalad run --input "*.jpg" "COMMAND"
 
    will retrieve all ``.jpg`` files prior to command execution.
 
@@ -415,7 +415,7 @@ for inputs and outputs. This is how it works:
 
 Instead of running
 
-.. code-block:: bash
+.. code-block:: console
 
    $ datalad run -m "Resize logo for slides" \
    --input "recordings/longnow/.datalad/feed_metadata/logo_interval.jpg" \
@@ -424,7 +424,7 @@ Instead of running
 
 you could shorten this to
 
-.. code-block:: bash
+.. code-block:: console
    :emphasize-lines: 4
 
    $ datalad run -m "Resize logo for slides" \
@@ -443,7 +443,7 @@ the ``--input`` and ``--output`` specification done before.
 
    If multiple values are specified, e.g., as in
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ datalad run -m "move a few files around" \
       --input "file1" --input "file2" --input "file3" \
@@ -452,7 +452,7 @@ the ``--input`` and ``--output`` specification done before.
 
    the values will be joined by a space like this:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ datalad run -m "move a few files around" \
       --input "file1" --input "file2" --input "file3" \
@@ -464,7 +464,7 @@ the ``--input`` and ``--output`` specification done before.
 
    If you use globs for input specification, as in
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ datalad run -m "move a few files around" \
       --input "file*" \
@@ -473,7 +473,7 @@ the ``--input`` and ``--output`` specification done before.
 
    the globs will expanded in alphabetical order (like bash):
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ datalad run -m "move a few files around" \
       --input "file1" --input "file2" --input "file3" \

docs/basics/101-113-summary.rst

@@ -22,7 +22,7 @@ command, and discovered the concept of *locked* content.
   to the executed command (using the ``-i``/``--input`` flag) and/or its output (using the ``-o``/
   ``--output`` flag). The full command structure is:
 
-  .. code-block:: bash
+  .. code-block:: console
 
      $ datalad run -m "commit message here" --input "path/to/input/" --output "path/to/output" "command"
 

docs/basics/101-116-sharelocal.rst

@@ -201,7 +201,7 @@ and hostname of your computer. "This", you exclaim, excited about your own reali
    The :gitannexcmd:`whereis` command, finally, is where such a description
    can become handy: If you had created the dataset with
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ datalad create --description "course on DataLad-101 on my private laptop" -c text2git DataLad-101
 
@@ -339,9 +339,9 @@ To explicitly install all potential subdatasets *recursively*, that is,
 all of the subdatasets inside it as well, one can give the
 ``-r``/``--recursive`` option to :dlcmd:`get`:
 
-.. code-block:: bash
+.. code-block:: console
 
-  datalad get -n -r <subds>
+  $ datalad get -n -r <subds>
 
 This would install the ``subds`` subdataset and all potential further
 subdatasets inside of it, and the meta data about file hierarchies would
@@ -359,9 +359,9 @@ However, there is a middle way [#f1]_: The ``--recursion-limit`` option let's
 you specify how many levels of subdatasets should be installed together
 with the first subdataset:
 
-.. code-block:: bash
+.. code-block:: console
 
-  datalad get -n -r --recursion-limit 1 <subds>
+  $ datalad get -n -r --recursion-limit 1 <subds>
 
 
 To summarize what you learned in this section, write a note on how to

docs/basics/101-122-config.rst

@@ -49,10 +49,10 @@ At one point in time, you likely followed instructions such as
 in :ref:`install` and configured your
 *Git identity* with the commands:
 
-.. code-block:: bash
+.. code-block:: console
 
-   git config --global --add user.name "Elena Piscopia"
-   git config --global --add user.email elena@example.net
+   $ git config --global --add user.name "Elena Piscopia"
+   $ git config --global --add user.email elena@example.net
 
 "What the above commands do is very simple: They search for
 a specific configuration file, and set the variables specified
@@ -183,9 +183,9 @@ system-wide configuration.
 If you would want to change this existing line in your ``.git/config``
 file, you would replace ``--add`` with ``--replace-all`` such as in:
 
-.. code-block:: bash
+.. code-block:: console
 
-   git config --local --replace-all core.editor "vim"
+   $ git config --local --replace-all core.editor "vim"
 
 to configure :term:`vim` to be your default editor.
 Note that while being a good toy example, it is not a common thing to
@@ -341,14 +341,14 @@ The next section will talk about them.
 
          1) Open up the file with an editor for your choice (e.g., `nano <https://www.howtogeek.com/42980/the-beginners-guide-to-nano-the-linux-command-line-text-editor>`_), and either paste the following configuration or edit it if it already exists:
 
-         .. code-block:: bash
+         .. code-block:: ini
 
             [core]
                 editor = nano
 
          2) Run the following command, but exchange ``nano`` with an editor of your choice:
 
-         .. code-block:: bash
+         .. code-block:: ini
 
             $ git config --global --add core.editor "nano"
 

docs/basics/101-123-config2.rst

@@ -163,9 +163,9 @@ Below is a minimally functional example on how to apply the configuration and ho
 
 Let's create a dataset hierarchy to work with (note that we concatenate multiple commands into a single line using bash's "and" ``&&`` operator):
 
-.. code-block:: bash
+.. code-block:: console
 
-    # create a superdataset with two subdatasets
+    $ # create a superdataset with two subdatasets
     $ datalad create superds && datalad -C superds create -d . subds1 && datalad -C superds create -d . subds2
     create(ok): /tmp/superds (dataset)
     add(ok): subds1 (file)
@@ -179,9 +179,9 @@ Let's create a dataset hierarchy to work with (note that we concatenate multiple
 
 Next, we create subdatasets in the subdatasets:
 
-.. code-block:: bash
+.. code-block:: console
 
-    # create two subdatasets in subds1
+    $ # create two subdatasets in subds1
     $ datalad -C superds/subds1 create -d . subsubds1 && datalad -C superds/subds1 create -d . subsubds2
     add(ok): subsubds1 (file)
     add(ok): .gitmodules (file)
@@ -205,7 +205,7 @@ Next, we create subdatasets in the subdatasets:
 
 Here is the directory structure:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cd ../ && tree
     .
@@ -216,40 +216,40 @@ Here is the directory structure:
         ├── subsubds1
         └── subsubds2
 
-    # save in the superdataset
+    $ # save in the superdataset
     datalad save -m "add a few sub and subsub datasets"
     add(ok): subds1 (file)
     add(ok): subds2 (file)
     save(ok): . (dataset)
 
 Now, we can apply the ``datalad-recursiveinstall`` configuration to skip recursive installations for ``subds1``
 
-.. code-block:: bash
+.. code-block:: console
 
     $ git config -f .gitmodules --add submodule.subds1.datalad-recursiveinstall skip
 
-    # save this configuration
+    $ # save this configuration
     $ datalad save -m "prevent recursion into subds1, unless explicitly given as path"
     add(ok): .gitmodules (file)
     save(ok): . (dataset)
 
 
 If the dataset is cloned, and someone runs a recursive :dlcmd:`get`, the subdatasets of ``subds1`` will not be installed, the subdatasets of ``subds2``, however, will be.
 
-.. code-block:: bash
+.. code-block:: console
 
-    # clone the dataset somewhere else
+    $ # clone the dataset somewhere else
     $ cd ../ && datalad clone superds clone_of_superds
     [INFO   ] Cloning superds into '/tmp/clone_of_superds'
     install(ok): /tmp/clone_of_superds (dataset)
 
-    # recursively get all contents (without data)
+    $ # recursively get all contents (without data)
     $ cd clone_of_superds && datalad get -n -r .
     get(ok): /tmp/clone_of_superds/subds2 (dataset)
     get(ok): /tmp/clone_of_superds/subds2/subsubds1 (dataset)
     get(ok): /tmp/clone_of_superds/subds2/subsubds2 (dataset)
 
-    # only subsubds of subds2 are installed, not of subds1:
+    $ # only subsubds of subds2 are installed, not of subds1:
     $ tree
     .
     ├── subds1
@@ -261,7 +261,7 @@ If the dataset is cloned, and someone runs a recursive :dlcmd:`get`, the subdata
 
 Nevertheless, if ``subds1`` is provided with an explicit path, its subdataset ``subsubds`` will be cloned, essentially overriding the configuration:
 
-.. code-block:: bash
+.. code-block:: console
 
     $  datalad get -n -r subds1 && tree
     install(ok): /tmp/clone_of_superds/subds1 (dataset) [Installed subdataset in order to get /tmp/clone_of_superds/subds1]
@@ -504,7 +504,7 @@ Write a note about configurations in datasets into ``notes.txt``.
          a ``.pdf`` file has MIME type ``application/pdf``. You can find out the MIME type
          of a file by running:
 
-         .. code-block:: bash
+         .. code-block:: console
 
             $ file --mime-type path/to/file
 
@@ -514,7 +514,7 @@ Write a note about configurations in datasets into ``notes.txt``.
          specified in there take precedence over rules in ``.gitattributes``. You can set
          them using the :gitcmd:`config` command:
 
-         .. code-block:: bash
+         .. code-block:: console
 
             $ git config annex.largefiles 'largerthan=100kb and not (include=*.c or include=*.h)'