Fixed #24358 -- Corrected code-block directives for console sessions.

docs/howto/deployment/wsgi/uwsgi.txt

@@ -24,7 +24,7 @@ The uWSGI wiki describes several `installation procedures`_. Using pip, the
 Python package manager, you can install any uWSGI version with a single
 command. For example:
 
-.. code-block:: bash
+.. code-block:: console
 
     # Install current stable version.
     $ pip install uwsgi

docs/howto/outputting-pdf.txt

@@ -24,7 +24,7 @@ The ReportLab library is `available on PyPI`_. A `user guide`_ (not
 coincidentally, a PDF file) is also available for download.
 You can install ReportLab with ``pip``:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ pip install reportlab
 

docs/howto/upgrade-version.txt

@@ -52,7 +52,7 @@ might want to set up a new environment with all the dependencies first.
 Exactly which steps you will need to take depends on your installation process.
 The most convenient way is to use pip_ with the ``--upgrade`` or ``-U`` flag:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ pip install -U Django
 
@@ -74,7 +74,7 @@ warnings are silenced by default. It is useful to turn the warnings on so they
 are shown in the test output (you can also use the flag if you test your app
 manually using ``manage.py runserver``):
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python -Wall manage.py test
 

docs/internals/contributing/writing-code/coding-style.txt

@@ -48,7 +48,7 @@ Imports
 
   Quick start:
 
-  .. code-block:: bash
+  .. code-block:: console
 
       $ pip install isort
       $ isort -rc .

docs/internals/contributing/writing-code/unit-tests.txt

@@ -2,6 +2,8 @@
 Unit tests
 ==========
 
+.. highlight:: console
+
 Django comes with a test suite of its own, in the ``tests`` directory of the
 code base. It's our policy to make sure all tests pass at all times.
 
@@ -26,9 +28,7 @@ the other optional test dependencies.
 
 Running the tests requires a Django settings module that defines the
 databases to use. To make it easy to get started, Django provides and uses a
-sample settings module that uses the SQLite database. To run the tests:
-
-.. code-block:: bash
+sample settings module that uses the SQLite database. To run the tests::
 
    $ git clone https://github.com/django/django.git django-repo
    $ cd django-repo/tests
@@ -96,9 +96,7 @@ tests by appending the names of the test modules to ``runtests.py`` on the
 command line.
 
 For example, if you'd like to run tests only for generic relations and
-internationalization, type:
-
-.. code-block:: bash
+internationalization, type::
 
    $ ./runtests.py --settings=path.to.settings generic_relations i18n
 
@@ -107,15 +105,11 @@ directory name there is the name of a test.
 
 If you just want to run a particular class of tests, you can specify a list of
 paths to individual test classes. For example, to run the ``TranslationTests``
-of the ``i18n`` module, type:
-
-.. code-block:: bash
+of the ``i18n`` module, type::
 
    $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
 
-Going beyond that, you can specify an individual test method like this:
-
-.. code-block:: bash
+Going beyond that, you can specify an individual test method like this::
 
    $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
 
@@ -125,9 +119,7 @@ Running the Selenium tests
 Some tests require Selenium and a Web browser (Firefox, Google Chrome, or
 Internet Explorer). To allow those tests to be run rather than skipped, you must
 install the selenium_ package into your Python path and run the tests with the
-``--selenium`` option:
-
-.. code-block:: bash
+``--selenium`` option::
 
    $ ./runtests.py --settings=test_sqlite --selenium admin_inlines
 
@@ -154,9 +146,7 @@ dependencies:
 
 You can find these dependencies in `pip requirements files`_ inside the
 ``tests/requirements`` directory of the Django source tree and install them
-like so:
-
-.. code-block:: bash
+like so::
 
    $ pip install -r tests/requirements/py3.txt  # Python 2: py2.txt
 
@@ -193,15 +183,11 @@ Contributors are encouraged to run coverage on the test suite to identify areas
 that need additional tests. The coverage tool installation and use is described
 in :ref:`testing code coverage<topics-testing-code-coverage>`.
 
-To run coverage on the Django test suite using the standard test settings:
-
-.. code-block:: bash
+To run coverage on the Django test suite using the standard test settings::
 
    $ coverage run ./runtests.py --settings=test_sqlite
 
-After running coverage, generate the html report by running:
-
-.. code-block:: bash
+After running coverage, generate the html report by running::
 
    $ coverage html
 
@@ -230,9 +216,7 @@ Many test failures with ``UnicodeEncodeError``
 If the ``locales`` package is not installed, some tests will fail with a
 ``UnicodeEncodeError``.
 
-You can resolve this on Debian-based systems, for example, by running:
-
-.. code-block:: bash
+You can resolve this on Debian-based systems, for example, by running::
 
     $ apt-get install locales
     $ dpkg-reconfigure locales
@@ -249,9 +233,7 @@ it possible to identify a small number of tests that may be related to the
 failure.
 
 For example, suppose that the failing test that works on its own is
-``ModelTest.test_eq``, then using:
-
-.. code-block:: bash
+``ModelTest.test_eq``, then using::
 
     $ ./runtests.py --bisect basic.tests.ModelTest.test_eq
 
@@ -265,9 +247,7 @@ failing tests is minimized.
 
 The ``--pair`` option runs the given test alongside every other test from the
 suite, letting you check if another test has side-effects that cause the
-failure. So:
-
-.. code-block:: bash
+failure. So::
 
     $ ./runtests.py --pair basic.tests.ModelTest.test_eq
 
@@ -276,25 +256,19 @@ will pair ``test_eq`` with every test label.
 With both ``--bisect`` and ``--pair``, if you already suspect which cases
 might be responsible for the failure, you may limit tests to be cross-analyzed
 by :ref:`specifying further test labels <runtests-specifying-labels>` after
-the first one:
-
-.. code-block:: bash
+the first one::
 
     $ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions
 
 You can also try running any set of tests in reverse using the ``--reverse``
 option in order to verify that executing tests in a different order does not
-cause any trouble:
-
-.. code-block:: bash
+cause any trouble::
 
     $ ./runtests.py basic --reverse
 
 If you wish to examine the SQL being run in failing tests, you can turn on
 :ref:`SQL logging <django-db-logger>` using the ``--debug-sql`` option. If you
-combine this with ``--verbosity=2``, all SQL queries will be output.
-
-.. code-block:: bash
+combine this with ``--verbosity=2``, all SQL queries will be output::
 
     $ ./runtests.py basic --debug-sql
 

docs/internals/howto-release-django.txt

@@ -2,6 +2,8 @@
 How is Django Formed?
 =====================
 
+.. highlight:: console
+
 This document explains how to release Django.
 
 **Please, keep these instructions up-to-date if you make changes!** The point
@@ -54,9 +56,7 @@ You'll need a few things before getting started:
   ``you@example.com`` is the email address associated with the key you want to
   use.
 
-* An install of some required Python packages:
-
-  .. code-block:: bash
+* An install of some required Python packages::
 
       $ pip install wheel twine
 
@@ -117,7 +117,7 @@ any time leading up to the actual release:
    rather than the releaser, but here are the steps. Provided you have an
    account on Transifex::
 
-        python scripts/manage_translations.py fetch
+        $ python scripts/manage_translations.py fetch
 
    and then commit the changed/added files (both .po and .mo). Sometimes there
    are validation errors which need to be debugged, so avoid doing this task
@@ -148,16 +148,16 @@ OK, this is the fun part, where we actually push out a release!
 #. A release always begins from a release branch, so you should make sure
    you're on a stable branch and up-to-date. For example::
 
-        git checkout stable/1.5.x
-        git pull
+        $ git checkout stable/1.5.x
+        $ git pull
 
 #. If this is a security release, merge the appropriate patches from
    ``django-private``. Rebase these patches as necessary to make each one a
    simple commit on the release branch rather than a merge commit. To ensure
    this, merge them with the ``--ff-only`` flag; for example::
 
-        git checkout stable/1.5.x
-        git merge --ff-only security/1.5.x
+        $ git checkout stable/1.5.x
+        $ git merge --ff-only security/1.5.x
 
    (This assumes ``security/1.5.x`` is a branch in the ``django-private`` repo
    containing the necessary security patches for the next release in the 1.5
@@ -193,7 +193,7 @@ OK, this is the fun part, where we actually push out a release!
 
 #. Tag the release using ``git tag``. For example::
 
-        git tag --sign --message="Tag 1.5.1" 1.5.1
+        $ git tag --sign --message="Tag 1.5.1" 1.5.1
 
    You can check your work by running ``git tag --verify <tag>``.
 
@@ -205,9 +205,7 @@ OK, this is the fun part, where we actually push out a release!
    create the release packages in a ``dist/`` directory. Note that we don't
    publish wheel files for 1.4.
 
-#. Generate the hashes of the release packages:
-
-   .. code-block:: bash
+#. Generate the hashes of the release packages::
 
         $ cd dist
         $ md5sum *
@@ -217,7 +215,9 @@ OK, this is the fun part, where we actually push out a release!
 #. Create a "checksums" file, ``Django-<<VERSION>>.checksum.txt`` containing
    the hashes and release information. Start with this template and insert the
    correct version, date, GPG key ID (from
-   ``gpg --list-keys --keyid-format LONG``), release URL, and checksums::
+   ``gpg --list-keys --keyid-format LONG``), release URL, and checksums:
+
+   .. code-block:: text
 
     This file contains MD5, SHA1, and SHA256 checksums for the source-code
     tarball of Django <<VERSION>>, released <<DATE>>.
@@ -276,22 +276,16 @@ Making the release(s) available to the public
 Now you're ready to actually put the release out there. To do this:
 
 #. Upload the release package(s) to the djangoproject server, replacing
-   A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release:
-
-   .. code-block:: bash
+   A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release::
 
         $ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
 
-#. Upload the checksum file(s):
-
-   .. code-block:: bash
+#. Upload the checksum file(s)::
 
         $ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt
 
 #. Test that the release packages install correctly using ``easy_install``
-   and ``pip``. Here's one method (which requires `virtualenvwrapper`__):
-
-   .. code-block:: bash
+   and ``pip``. Here's one method (which requires `virtualenvwrapper`__)::
 
         $ RELEASE_VERSION='1.7.2'
         $ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3`
@@ -318,9 +312,7 @@ Now you're ready to actually put the release out there. To do this:
    correct (proper version numbers, no stray ``.pyc`` or other undesirable
    files).
 
-#. Upload the release packages to PyPI:
-
-   .. code-block:: bash
+#. Upload the release packages to PyPI::
 
        $ twine upload -s dist/*
 
@@ -334,7 +326,7 @@ Now you're ready to actually put the release out there. To do this:
 #. Make the blog post announcing the release live.
 
 #. For a new version release (e.g. 1.5, 1.6), update the default stable version
-   of the docs by flipping the ``is_default`` flag to ``True`` on the
+   of the docs by flipping the ``is_default`` flag to `deployment/wsgi/uwsgi.html`True`` on the
    appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com``
    database (this will automatically flip it to ``False`` for all
    others); you can do this using the site's admin.

docs/intro/overview.txt

@@ -51,7 +51,7 @@ Install it
 Next, run the Django command-line utility to create the database tables
 automatically:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py migrate
 

docs/intro/tutorial01.txt

@@ -15,7 +15,7 @@ It'll consist of two parts:
 We'll assume you have :doc:`Django installed </intro/install>` already. You can
 tell Django is installed and which version by running the following command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python -c "import django; print(django.get_version())"
 
@@ -51,7 +51,7 @@ application-specific settings.
 From the command line, ``cd`` into a directory where you'd like to store your
 code, then run the following command:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ django-admin startproject mysite
 
@@ -190,7 +190,7 @@ Some of these applications makes use of at least one database table, though,
 so we need to create the tables in the database before we can use them. To do
 that, run the following command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py migrate
 
@@ -217,7 +217,7 @@ The development server
 Let's verify your Django project works. Change into the outer :file:`mysite` directory, if
 you haven't already, and run the following commands:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ python manage.py runserver
 
@@ -255,7 +255,7 @@ It worked!
     it as a command-line argument. For instance, this command starts the server
     on port 8080:
 
-    .. code-block:: bash
+    .. code-block:: console
 
         $ python manage.py runserver 8080
 
@@ -263,7 +263,7 @@ It worked!
     listen on all public IPs (useful if you want to show off your work on other
     computers), use:
 
-    .. code-block:: bash
+    .. code-block:: console
 
         $ python manage.py runserver 0.0.0.0:8000
 
@@ -305,7 +305,7 @@ imported as its own top-level module, rather than a submodule of ``mysite``.
 To create your app, make sure you're in the same directory as :file:`manage.py`
 and type this command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py startapp polls
 
@@ -434,7 +434,7 @@ look like this:
 
 Now Django knows to include the ``polls`` app. Let's run another command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py makemigrations polls
 
@@ -464,7 +464,7 @@ schema automatically - that's called :djadmin:`migrate`, and we'll come to it in
 moment - but first, let's see what SQL that migration would run. The
 :djadmin:`sqlmigrate` command takes migration names and returns their SQL:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py sqlmigrate polls 0001
 
@@ -534,7 +534,7 @@ your project without making migrations or touching the database.
 
 Now, run :djadmin:`migrate` again to create those model tables in your database:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py migrate
     Operations to perform:
@@ -577,7 +577,7 @@ Playing with the API
 Now, let's hop into the interactive Python shell and play around with the free
 API Django gives you. To invoke the Python shell, use this command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py shell
 

docs/intro/tutorial02.txt

@@ -27,7 +27,7 @@ Creating an admin user
 First we'll need to create a user who can login to the admin site. Run the
 following command:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py createsuperuser
 
@@ -60,7 +60,7 @@ server and explore it.
 
 Recall from Tutorial 1 that you start the development server like so:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py runserver
 
@@ -522,7 +522,7 @@ template directory in the source code of Django itself
     If you have difficulty finding where the Django source files are located
     on your system, run the following command:
 
-    .. code-block:: bash
+    .. code-block:: console
 
         $ python -c "
         import sys

docs/intro/whatsnext.txt

@@ -150,7 +150,7 @@ Unix ``grep`` utility to search for a phrase in all of the documentation. For
 example, this will show you each mention of the phrase "max_length" in any
 Django document:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ grep -r max_length /path/to/django/docs/
 
@@ -163,14 +163,14 @@ You can get a local copy of the HTML documentation following a few easy steps:
   plain text to HTML. You'll need to install Sphinx by either downloading
   and installing the package from the Sphinx Web site, or with ``pip``:
 
-  .. code-block:: bash
+  .. code-block:: console
 
         $ pip install Sphinx
 
 * Then, just use the included ``Makefile`` to turn the documentation into
   HTML:
 
-  .. code-block:: bash
+  .. code-block:: console
 
         $ cd path/to/django/docs
         $ make html

docs/ref/contrib/gis/install/geolibs.txt

@@ -58,7 +58,7 @@ __ http://www.gaia-gis.it/gaia-sins/
 On Debian/Ubuntu, you are advised to install the following packages which will
 install, directly or by dependency, the required geospatial libraries:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ sudo apt-get install binutils libproj-dev gdal-bin
 

docs/ref/contrib/gis/tutorial.txt

@@ -56,7 +56,7 @@ First, create a spatial database for your project.
 If you are using PostGIS, create the database from the :ref:`spatial database
 template <spatialdb_template>`:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ createdb -T template_postgis geodjango
 
@@ -66,7 +66,7 @@ template <spatialdb_template>`:
     create a database.  To create a user with ``CREATE DATABASE`` privileges in
     PostgreSQL, use the following commands:
 
-    .. code-block:: bash
+    .. code-block:: console
 
         $ sudo su - postgres
         $ createuser --createdb geo
@@ -84,14 +84,14 @@ Create a New Project
 Use the standard ``django-admin`` script to create a project called
 ``geodjango``:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ django-admin startproject geodjango
 
 This will initialize a new project. Now, create a ``world`` Django application
 within the ``geodjango`` project:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ cd geodjango
     $ python manage.py startapp world
@@ -137,7 +137,7 @@ The world borders data is available in this `zip file`__.  Create a ``data``
 directory in the ``world`` application, download the world borders data, and
 unzip. On GNU/Linux platforms, use the following commands:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ mkdir world/data
     $ cd world/data
@@ -166,7 +166,7 @@ Use ``ogrinfo`` to examine spatial data
 The GDAL ``ogrinfo`` utility allows examining the metadata of shapefiles or
 other vector data sources:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ ogrinfo world/data/TM_WORLD_BORDERS-0.3.shp
     INFO: Open of `world/data/TM_WORLD_BORDERS-0.3.shp'
@@ -177,7 +177,7 @@ other vector data sources:
 layer contains polygon data.  To find out more, we'll specify the layer name
 and use the ``-so`` option to get only the important summary information:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ ogrinfo -so world/data/TM_WORLD_BORDERS-0.3.shp TM_WORLD_BORDERS-0.3
     INFO: Open of `world/data/TM_WORLD_BORDERS-0.3.shp'
@@ -267,7 +267,7 @@ Run ``migrate``
 After defining your model, you need to sync it with the database. First,
 create a database migration:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py makemigrations
     Migrations for 'world':
@@ -277,7 +277,7 @@ create a database migration:
 Let's look at the SQL that will generate the table for the ``WorldBorder``
 model:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py sqlmigrate world 0001
 
@@ -314,7 +314,7 @@ This command should produce the following output:
 If this looks correct, run :djadmin:`migrate` to create this table in the
 database:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py migrate
     Operations to perform:
@@ -351,7 +351,7 @@ library that can work with all the vector data sources that OGR supports.
 
 First, invoke the Django shell:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py shell
 
@@ -515,7 +515,7 @@ A few notes about what's going on:
 
 Afterwards, invoke the Django shell from the ``geodjango`` project directory:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py shell
 
@@ -537,7 +537,7 @@ and generates a model definition and ``LayerMapping`` dictionary automatically.
 
 The general usage of the command goes as follows:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py ogrinspect [options] <data_source> <model_name> [options]
 
@@ -548,7 +548,7 @@ be used to further define how the model is generated.
 For example, the following command nearly reproduces the ``WorldBorder`` model
 and mapping dictionary created above, automatically:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py ogrinspect world/data/TM_WORLD_BORDERS-0.3.shp WorldBorder \
         --srid=4326 --mapping --multi
@@ -609,7 +609,7 @@ GeoDjango adds spatial lookups to the Django ORM.  For example, you
 can find the country in the ``WorldBorder`` table that contains
 a particular point.  First, fire up the management shell:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py shell
 
@@ -753,13 +753,13 @@ Next, edit your ``urls.py`` in the ``geodjango`` application folder as follows::
 
 Create an admin user:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py createsuperuser
 
 Next, start up the Django development server:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python manage.py runserver
 

docs/ref/django-admin.txt

@@ -38,7 +38,7 @@ be consistent, but any example can use ``manage.py`` just as well.
 Usage
 =====
 
-.. code-block:: bash
+.. code-block:: console
 
     $ django-admin <command> [options]
     $ manage.py <command> [options]

docs/releases/1.0-porting-guide.txt

@@ -556,7 +556,7 @@ need to reload your data. Do this after you have made the change to using
 To upgrade each application to use a ``DecimalField``, you can do the
 following, replacing ``<app>`` in the code below with each app's name:
 
-.. code-block:: bash
+.. code-block:: console
 
       $ ./manage.py dumpdata --format=xml <app> > data-dump.xml
       $ ./manage.py reset <app>
@@ -685,13 +685,13 @@ Subcommands must now precede options
 ``django-admin.py`` and ``manage.py`` now require subcommands to precede
 options. So:
 
-.. code-block:: bash
+.. code-block:: console
 
       $ django-admin.py --settings=foo.bar runserver
 
 ...no longer works and should be changed to:
 
-.. code-block:: bash
+.. code-block:: console
 
       $ django-admin.py runserver --settings=foo.bar
 

docs/topics/i18n/timezones.txt

@@ -34,7 +34,7 @@ but may not be mandatory depending on your particular database backend,
 operating system and time zone. If you encounter an exception querying dates
 or times, please try installing it before filing a bug. It's as simple as:
 
-.. code-block:: bash
+.. code-block:: console
 
     $ pip install pytz
 

docs/topics/install.txt

@@ -140,9 +140,9 @@ uninstalling is as simple as deleting the ``django`` directory from your Python
 ``site-packages``. To find the directory you need to remove, you can run the
 following at your shell prompt (not the interactive Python prompt):
 
-.. code-block:: bash
+.. code-block:: console
 
-    python -c "import sys; sys.path = sys.path[1:]; import django; print(django.__path__)"
+    $ python -c "import sys; sys.path = sys.path[1:]; import django; print(django.__path__)"
 
 
 .. _install-django-code:
@@ -256,18 +256,18 @@ latest bug fixes and improvements, follow these instructions:
 2. Check out Django's main development branch (the 'trunk' or 'master') like
    so:
 
-   .. code-block:: bash
+   .. code-block:: console
 
-       git clone git://github.com/django/django.git django-trunk
+        $ git clone git://github.com/django/django.git django-trunk
 
    This will create a directory ``django-trunk`` in your current directory.
 
 3. Make sure that the Python interpreter can load Django's code. The most
    convenient way to do this is via pip_. Run the following command:
 
-   .. code-block:: bash
+   .. code-block:: console
 
-       sudo pip install -e django-trunk/
+        $ sudo pip install -e django-trunk/
 
    (If using a virtualenv_ you can omit ``sudo``.)
 
@@ -302,9 +302,9 @@ with a checkout of Django's latest code in it. Then add a ``.pth`` file
 containing the full path to the ``django-trunk`` directory to your system's
 ``site-packages`` directory. For example, on a Unix-like system:
 
-.. code-block:: bash
+.. code-block:: console
 
-    echo WORKING-DIR/django-trunk > SITE-PACKAGES-DIR/django.pth
+    $ echo WORKING-DIR/django-trunk > SITE-PACKAGES-DIR/django.pth
 
 In the above line, change ``WORKING-DIR/django-trunk`` to match the full path
 to your new ``django-trunk`` directory, and change ``SITE-PACKAGES-DIR`` to
@@ -314,9 +314,9 @@ The location of the ``site-packages`` directory depends on the operating
 system, and the location in which Python was installed. To find your system's
 ``site-packages`` location, execute the following:
 
-.. code-block:: bash
+.. code-block:: console
 
-    python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
+    $ python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
 
 (Note that this should be run from a shell prompt, not a Python interactive
 prompt.)
@@ -334,9 +334,9 @@ On Unix-like systems, create a symbolic link to the file
 ``django-trunk/django/bin/django-admin`` in a directory on your system
 path, such as ``/usr/local/bin``. For example:
 
-.. code-block:: bash
+.. code-block:: console
 
-    ln -s WORKING-DIR/django-trunk/django/bin/django-admin.py /usr/local/bin/
+    $ ln -s WORKING-DIR/django-trunk/django/bin/django-admin.py /usr/local/bin/
 
 (In the above line, change WORKING-DIR to match the full path to your new
 ``django-trunk`` directory.)

docs/topics/testing/tools.txt

@@ -760,9 +760,9 @@ to change the default address (in the case, for example, where the 8081 port is
 already taken) then you may pass a different one to the :djadmin:`test` command
 via the :djadminopt:`--liveserver` option, for example:
 
-.. code-block:: bash
+.. code-block:: console
 
-    ./manage.py test --liveserver=localhost:8082
+    $ ./manage.py test --liveserver=localhost:8082
 
 Another way of changing the default server address is by setting the
 `DJANGO_LIVE_TEST_SERVER_ADDRESS` environment variable somewhere in your
@@ -778,9 +778,9 @@ tests might randomly fail with an "Address already in use" error. To avoid this
 problem, you can pass a comma-separated list of ports or ranges of ports (at
 least as many as the number of potential parallel processes). For example:
 
-.. code-block:: bash
+.. code-block:: console
 
-    ./manage.py test --liveserver=localhost:8082,8090-8100,9000-9200,7041
+    $ ./manage.py test --liveserver=localhost:8082,8090-8100,9000-9200,7041
 
 Then, during test execution, each new live test server will try every specified
 port until it finds one that is free and takes it.
@@ -791,9 +791,9 @@ To demonstrate how to use ``LiveServerTestCase``, let's write a simple Selenium
 test. First of all, you need to install the `selenium package`_ into your
 Python path:
 
-.. code-block:: bash
+.. code-block:: console
 
-   pip install selenium
+    $ pip install selenium
 
 Then, add a ``LiveServerTestCase``-based test to your app's tests module
 (for example: ``myapp/tests.py``). The code for this test may look as follows::
@@ -824,9 +824,9 @@ Then, add a ``LiveServerTestCase``-based test to your app's tests module
 
 Finally, you may run the test as follows:
 
-.. code-block:: bash
+.. code-block:: console
 
-    ./manage.py test myapp.tests.MySeleniumTests.test_login
+    $ ./manage.py test myapp.tests.MySeleniumTests.test_login
 
 This example will automatically open Firefox then go to the login page, enter
 the credentials and press the "Log in" button. Selenium offers other drivers in