use code-block directives for non-python examples

doc/getting-started.rst

@@ -26,12 +26,16 @@ Getting started with Buildout
 First steps
 ===========
 
-The easiest way to install Buildout is with pip::
+The easiest way to install Buildout is with pip:
+
+.. code-block:: console
 
   pip install zc.buildout
 
 To use Buildout, you need to provide a Buildout configuration. Here is
-a minimal configuration::
+a minimal configuration:
+
+.. code-block:: ini
 
   [buildout]
   parts =
@@ -41,7 +45,9 @@ a minimal configuration::
    >>> write(src, 'buildout.cfg')
 
 A minimal (and useless) Buildout configuration has a ``buildout`` section
-with a parts option.  If we run Buildout::
+with a parts option.  If we run Buildout:
+
+.. code-block:: console
 
   buildout
 
@@ -97,7 +103,9 @@ example that illustrates a number of ways that Buildout can make
 things easier.
 
 We'll start by adding a part to install the server software.  We'll
-update our Buildout configuration to add a ``zeo`` part::
+update our Buildout configuration to add a ``zeo`` part:
+
+.. code-block:: ini
 
   [buildout]
   parts = zeo
@@ -130,7 +138,9 @@ eggs
   addition, any scripts provided by the listed requirements (but not
   their dependencies) are installed in the ``bin`` directory.
 
-If we run this [#gcc]_::
+If we run this [#gcc]_:
+
+.. code-block:: console
 
   buildout
 
@@ -146,7 +156,9 @@ Then a number of things will happen:
 - ``ZEO`` and its dependencies will be downloaded and installed. (ZEO
   is a small Python database server.)
 
-  After this, the eggs directory will look something like::
+  After this, the eggs directory will look something like:
+
+  .. code-block:: console
 
     $ ls -l eggs
     total 0
@@ -169,9 +181,11 @@ Then a number of things will happen:
 
      >>> yup([n for n in ls('eggs') if n.startswith('ZEO-4.3.1-')])
 
-- A number of scripts will be installed in the ``bin`` directory::
+- A number of scripts will be installed in the ``bin`` directory:
 
-    bash-3.2$ ls -l bin
+  .. code-block:: console
+
+    $ ls -l bin
     total 40
     -rwxr-xr-x  1 jim  staff  861 Feb 15 13:07 runzeo
     -rwxr-xr-x  1 jim  staff  861 Feb 15 13:07 zeo-nagios
@@ -192,7 +206,9 @@ be used with a dedicated daemonizer like `zdaemon
 <https://pypi.python.org/pypi/zdaemon>`_ or `supervisord
 <http://supervisord.org/>`_.  We'll use a `recipe to set up zdaemon
 <https://pypi.python.org/pypi/zc.zdaemonrecipe>`_.  Our Buildout
-configuration becomes::
+configuration becomes:
+
+.. code-block:: ini
 
   [buildout]
   parts = zeo server
@@ -239,7 +255,9 @@ There are a couple of interesting things to note about this option:
   ``zc.zdaemonrecipe`` recipe combines the program value into a single
   line.
 
-If we run Buildout::
+If we run Buildout:
+
+.. code-block:: console
 
   buildout
 
@@ -251,11 +269,15 @@ If we run Buildout::
   the eggs directory.
 
 - A ``server`` script is added to the ``bin`` directory.  This script
-  is generated by the recipe.  It can be run like::
+  is generated by the recipe.  It can be run like:
+
+  .. code-block:: console
 
     bin/server start
 
-  to start a server and::
+  to start a server and:
+
+  .. code-block:: console
 
     bin/server stop
 
@@ -263,7 +285,9 @@ If we run Buildout::
   generated by the recipe in ``parts/server/zdaemon.conf``.
 
 - A zdaemon configuration script is generated in
-  ``parts/server/zdaemon.conf`` that looks something like::
+  ``parts/server/zdaemon.conf`` that looks something like:
+
+  .. code-block:: xml
 
     <runner>
       daemon on
@@ -365,7 +389,9 @@ If it didn't do this, then an older buildout would likely have
 different versions of Python packages than newer buildouts.
 
 To speed things up, you can use the ``-N`` Buildout option to tell
-Buildout to *not* check for newer versions of Python requirements::
+Buildout to *not* check for newer versions of Python requirements:
+
+.. code-block:: console
 
   buildout -N
 
@@ -380,7 +406,9 @@ Pinned versions
 _______________
 
 You can also pin required versions in two ways.  You can specify them
-where you list them, as in::
+where you list them, as in:
+
+.. code-block:: ini
 
   [zeo]
   recipe = zc.recipe.egg
@@ -404,7 +432,9 @@ where you list them, as in::
 
 In this example, we've requested a version of ZEO less than 5.0.
 
-The more common way to pin version is using a ``versions`` section::
+The more common way to pin version is using a ``versions`` section:
+
+.. code-block:: ini
 
   [buildout]
   parts = zeo server
@@ -432,7 +462,9 @@ The more common way to pin version is using a ``versions`` section::
    >>> nope('ZEO = 4.3.1' in read('out'))
 
 Larger projects may need to pin many versions, so it's common to put
-versions in their own file::
+versions in their own file:
+
+.. code-block:: ini
 
   [buildout]
   extends = versions.cfg
@@ -457,7 +489,9 @@ Here, we've used the Buildout ``extends`` option to say that
 configurations should be read from the named file (or files) and that
 configuration in the current file should override configuration in the
 extended files.  To continue the example, our ``versions.cfg`` file
-might look like::
+might look like:
+
+.. code-block:: ini
 
   [versions]
   ZEO = 4.3.1
@@ -471,7 +505,9 @@ might look like::
    >>> nope('ZEO = 4.3.1' in read('out'))
 
 We can use the ``update-versions-file`` option to ask Buildout to
-maintain our ``versions.cfg`` file for us::
+maintain our ``versions.cfg`` file for us:
+
+.. code-block:: ini
 
   [buildout]
   extends = versions.cfg
@@ -539,7 +575,9 @@ versions.  This only happens if you run Buildout from a buildout's own
 ``bin`` directory.
 
 We can use Buildout's ``bootstrap`` command to install a local
-buildout script::
+buildout script:
+
+.. code-block:: console
 
   buildout bootstrap
 
@@ -549,7 +587,9 @@ buildout script::
    >>> run_buildout(src)
    >>> yup('buildout' in ls('bin'))
 
-Then, if the installed script is used::
+Then, if the installed script is used:
+
+.. code-block:: console
 
   bin/buildout
 
@@ -566,7 +606,9 @@ Python development projects
 
 A very common Buildout use case is to manage the development of a
 library or main part of an application written in Python.  Buildout
-facilitates this with the ``develop`` option::
+facilitates this with the ``develop`` option:
+
+.. code-block:: ini
 
    [buildout]
    develop = .
@@ -621,7 +663,9 @@ install_requires
 
 A *minimal* [#typical-dev-project]_ development Buildout configuration
 for a project with a setup script like the one above might look
-something like this::
+something like this:
+
+.. code-block:: ini
 
    [buildout]
    develop = .
@@ -645,7 +689,9 @@ There's a new option, ``interpreter``, which names an *interpreter*
 script to be generated. An interpreter script [#interpreter-script]_
 mimics a Python interpreter with its path set to include the
 requirements specified in the eggs option and their (transitive)
-dependencies.  We can run the interpreter::
+dependencies.  We can run the interpreter:
+
+.. code-block:: console
 
   bin/py
 
@@ -653,7 +699,9 @@ dependencies.  We can run the interpreter::
 
    >>> yup(os.getcwd() in read(path.strip()))
 
-To get an interactive Python prompt, or you can run a script with it::
+To get an interactive Python prompt, or you can run a script with it:
+
+.. code-block:: console
 
   bin/py somescript.py