diff mbox

[ovs-dev] doc: Correct type of highlighting

Message ID 20161223114629.23395-1-stephen@that.guru
State Accepted
Headers show

Commit Message

Stephen Finucane Dec. 23, 2016, 11:46 a.m. UTC 
Some recent changes marked code as Powershell when in fact it was DOS or
bash shell. This incorrect highlighting actually breaks the local build
(where warnings are treated as errors) as pygments is unable to lex all
the code as PowerShell. Fix these types.

Signed-off-by: Stephen Finucane <stephen@that.guru>
Fixes: b8d24cc8a ("doc: Misc Windows doc formatting fixes")
---
 Documentation/intro/install/windows.rst | 290 ++++++++++++++++----------------
 1 file changed, 148 insertions(+), 142 deletions(-)

Comments

Ben Pfaff Dec. 23, 2016, 4:54 p.m. UTC | #1 
On Fri, Dec 23, 2016 at 11:46:29AM +0000, Stephen Finucane wrote:
> Some recent changes marked code as Powershell when in fact it was DOS or
> bash shell. This incorrect highlighting actually breaks the local build
> (where warnings are treated as errors) as pygments is unable to lex all
> the code as PowerShell. Fix these types.
> 
> Signed-off-by: Stephen Finucane <stephen@that.guru>
> Fixes: b8d24cc8a ("doc: Misc Windows doc formatting fixes")

Thanks!  Applied to master.

I've been toying with the idea that the build should break if there are
any broken links (at least internal links) in the .rst files.  Is there
a practical way to make that happen?
Stephen Finucane Dec. 23, 2016, 6:50 p.m. UTC | #2 
On Fri, 2016-12-23 at 08:54 -0800, Ben Pfaff wrote:
> I've been toying with the idea that the build should break if there
> are
> any broken links (at least internal links) in the .rst files.  Is
> there
> a practical way to make that happen?

Any internal references (using the 'doc:' or 'ref:' roles) do raise a
warnings if the link's broken. This will cause a broken local build
because warnings are treated as errors, but ReadTheDocs is less
stringent (presumably to ensure docs are available as much as
possible). I guess we could change this but it would only serve to
highlight issues once they've already been committed. A better approach
would be to always build the docs locally before committing them to
highlight potential issues, but this is easily forgotten (as seen in
this instance). Any ideas how we could automate this?

Stephen
Ben Pfaff Dec. 23, 2016, 7:31 p.m. UTC | #3 
On Fri, Dec 23, 2016 at 06:50:41PM +0000, Stephen Finucane wrote:
> On Fri, 2016-12-23 at 08:54 -0800, Ben Pfaff wrote:
> > I've been toying with the idea that the build should break if there
> > are
> > any broken links (at least internal links) in the .rst files.  Is
> > there
> > a practical way to make that happen?
> 
> Any internal references (using the 'doc:' or 'ref:' roles) do raise a
> warnings if the link's broken. This will cause a broken local build
> because warnings are treated as errors, but ReadTheDocs is less
> stringent (presumably to ensure docs are available as much as
> possible). I guess we could change this but it would only serve to
> highlight issues once they've already been committed. A better approach
> would be to always build the docs locally before committing them to
> highlight potential issues, but this is easily forgotten (as seen in
> this instance). Any ideas how we could automate this?

We have several targets that run on every plain "make" to check various
correctness and style properties.  For example, take a look at the
manpage-check and flake8-check targets in the top-level Makefile.am.  It
would be nice to add a similar target that checked the documentation, at
least in the case where the appropriate tools are installed.  Then any
developer who runs "make" (and has the tools) would find the issue
immediately, because the build would fail.
Stephen Finucane Dec. 23, 2016, 11:05 p.m. UTC | #4 
On Fri, 2016-12-23 at 11:31 -0800, Ben Pfaff wrote:
> On Fri, Dec 23, 2016 at 06:50:41PM +0000, Stephen Finucane wrote:
> > On Fri, 2016-12-23 at 08:54 -0800, Ben Pfaff wrote:
> > > I've been toying with the idea that the build should break if
> > > there
> > > are
> > > any broken links (at least internal links) in the .rst files.  Is
> > > there
> > > a practical way to make that happen?
> > 
> > Any internal references (using the 'doc:' or 'ref:' roles) do raise
> > a
> > warnings if the link's broken. This will cause a broken local build
> > because warnings are treated as errors, but ReadTheDocs is less
> > stringent (presumably to ensure docs are available as much as
> > possible). I guess we could change this but it would only serve to
> > highlight issues once they've already been committed. A better
> > approach
> > would be to always build the docs locally before committing them to
> > highlight potential issues, but this is easily forgotten (as seen
> > in
> > this instance). Any ideas how we could automate this?
> 
> We have several targets that run on every plain "make" to check
> various
> correctness and style properties.  For example, take a look at the
> manpage-check and flake8-check targets in the top-level
> Makefile.am.  It
> would be nice to add a similar target that checked the documentation,
> at
> least in the case where the appropriate tools are installed.  Then
> any
> developer who runs "make" (and has the tools) would find the issue
> immediately, because the build would fail.

Gotcha. Did some rooting around and found a similar tool in Sphinx
(which gets cooler by the day). Just sent patches to implement this.
Let me know what you think.

Stephen
diff mbox

Patch

diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst
index 1ba9b63..23a5a9b 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -105,9 +105,10 @@  The following explains the steps in some detail.
 .. note::
 
    Commands prefixed by ``$`` must be run in the Bash shell provided by MinGW.
-   Open vSwitch commands, such as ``ovs-dpctl`` are shown running under
-   PowerShell (``>`` prefix) but will also run under Bash. The remainder,
-   prefixed by ``>``, are PowerShell commands and must be run in PowerShell.
+   Open vSwitch commands, such as ``ovs-dpctl`` are shown running under the DOS
+   shell (``cmd.exe``), as indicated by the ``>`` prefix, but will also run
+   under Bash. The remainder, prefixed by ``>``, are PowerShell commands and
+   must be run in PowerShell.
 
 Install Requirements
 --------------------
@@ -132,7 +133,7 @@  you pulled the sources directly from an Open vSwitch Git tree or got a
 Git tree snapshot, then run boot.sh in the top source directory to build
 the "configure" script:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ ./boot.sh
 
@@ -145,7 +146,7 @@  Configure the package by running the configure script.  You should provide some
 configure options to choose the right compiler, linker, libraries, Open vSwitch
 component installation directories, etc. For example:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ ./configure CC=./build-aux/cccl LD="$(which link)" \
        LIBS="-lws2_32 -liphlpapi -lwbemuuid -lole32 -loleaut32" \
@@ -161,7 +162,7 @@  component installation directories, etc. For example:
 
 To configure with SSL support, add the requisite additional options:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ ./configure CC=./build-aux/cccl LD="`which link`"  \
        LIBS="-lws2_32 -liphlpapi -lwbemuuid -lole32 -loleaut32" \
@@ -173,7 +174,7 @@  To configure with SSL support, add the requisite additional options:
 
 Finally, to the kernel module also:
 
-.. code-block:: bash
+.. code-block:: console
 
    $ ./configure CC=./build-aux/cccl LD="`which link`" \
        LIBS="-lws2_32 -liphlpapi -lwbemuuid -lole32 -loleaut32" \
@@ -203,7 +204,7 @@  building on Linux, FreeBSD, or NetBSD.
 
 #. Run make for the ported executables in the top source directory, e.g.:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ make
 
@@ -223,19 +224,19 @@  building on Linux, FreeBSD, or NetBSD.
 
 #. To run all the unit tests in Open vSwitch, one at a time:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ make check
 
    To run all the unit tests in Open vSwitch, up to 8 in parallel:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ make check TESTSUITEFLAGS="-j8"
 
 #. To install all the compiled executables on the local machine, run:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ make install
 
@@ -268,11 +269,11 @@  Now run ``./uninstall.cmd`` to remove the old extension. Once complete, run
 turn on ``TESTSIGNING`` boot option or 'Disable Driver Signature
 Enforcement' during boot.  The following commands can be used:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
-   PS > bcdedit /set TESTSIGNING ON
-   PS > bcdedit /set nointegritychecks ON
+   > bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS
+   > bcdedit /set TESTSIGNING ON
+   > bcdedit /set nointegritychecks ON
 
 .. note::
 
@@ -286,7 +287,7 @@  to work (covered later).
 The command to create a new switch named 'OVS-Extended-Switch' using a physical
 NIC named 'Ethernet 1' is:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
    PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1"
 
@@ -299,7 +300,7 @@  In the properties of any switch, you should should now see "Open vSwitch
 Extension" under 'Extensions'.  Click the check box to enable the extension.
 An alternative way to do the same is to run the following command:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
    PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch
 
@@ -322,18 +323,18 @@  database, ovsdb-server. Each machine on which Open vSwitch is installed should
 run its own copy of ovsdb-server. Before ovsdb-server itself can be started,
 configure a database that it can use:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovsdb-tool create C:\openvswitch\etc\openvswitch\conf.db \
-        C:\openvswitch\usr\share\openvswitch\vswitch.ovsschema
+   > ovsdb-tool create C:\openvswitch\etc\openvswitch\conf.db \
+       C:\openvswitch\usr\share\openvswitch\vswitch.ovsschema
 
 Configure ovsdb-server to use database created above and to listen on a Unix
 domain socket:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovsdb-server -vfile:info --remote=punix:db.sock --log-file \
-        --pidfile --detach
+   > ovsdb-server -vfile:info --remote=punix:db.sock --log-file \
+       --pidfile --detach
 
 .. note::
 
@@ -343,32 +344,32 @@  Initialize the database using ovs-vsctl. This is only necessary the first time
 after you create the database with ovsdb-tool, though running it at any time is
 harmless:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl --no-wait init
+   > ovs-vsctl --no-wait init
 
 .. tip::
 
    If you would later like to terminate the started ovsdb-server, run:
 
-   .. code-block:: powershell
+   .. code-block:: doscon
 
-      PS > ovs-appctl -t ovsdb-server exit
+      > ovs-appctl -t ovsdb-server exit
 
 Start the main Open vSwitch daemon, telling it to connect to the same Unix
 domain socket:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vswitchd -vfile:info --log-file --pidfile --detach
+   > ovs-vswitchd -vfile:info --log-file --pidfile --detach
 
 .. tip::
 
    If you would like to terminate the started ovs-vswitchd, run:
 
-   .. code-block:: powershell
+   .. code-block:: doscon
 
-      PS > ovs-appctl exit
+      > ovs-appctl exit
 
 .. note::
 
@@ -386,10 +387,10 @@  Add bridges
 Let's start by creating an integration bridge, ``br-int`` and a PIF bridge,
 ``br-pif``:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PW > ovs-vsctl add-br br-int
-   PW > ovs-vsctl add-br br-pif
+   > ovs-vsctl add-br br-int
+   > ovs-vsctl add-br br-pif
 
 .. note::
 
@@ -400,16 +401,16 @@  Let's start by creating an integration bridge, ``br-int`` and a PIF bridge,
 
 Validate that ports are added by dumping from both ovs-dpctl and ovs-vsctl:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-dpctl show
+   > ovs-dpctl show
    system@ovs-system:
            lookups: hit:0 missed:0 lost:0
            flows: 0
            port 2: br-pif (internal)     <<< internal port on 'br-pif' bridge
            port 1: br-int (internal)     <<< internal port on 'br-int' bridge
 
-   PS > ovs-vsctl show
+   > ovs-vsctl show
    a56ec7b5-5b1f-49ec-a795-79f6eb63228b
        Bridge br-pif
            Port br-pif
@@ -449,7 +450,7 @@  enable them and set the corresponding values to it to make them IP-able.
 
 As a whole example, if we issue the following in a powershell console:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
     PS > Get-NetAdapter | select Name,InterfaceDescription
     Name                   InterfaceDescription
@@ -468,15 +469,15 @@  We can see that we have a switch(external) created upon adapter name
 'Ethernet0' with the internal ports under name 'br-pif' and 'br-int'. Thus
 resulting into the following ovs-vsctl commands:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl add-port br-pif Ethernet0
+   > ovs-vsctl add-port br-pif Ethernet0
 
 Dumping the ports should show the additional ports that were just added:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PW > ovs-dpctl show
+   > ovs-dpctl show
    system@ovs-system:
            lookups: hit:0 missed:0 lost:0
            flows: 0
@@ -488,7 +489,7 @@  Dumping the ports should show the additional ports that were just added:
                                                        Hyper-V switch
            port 3: Ethernet0                       <<< Physical NIC
 
-   PW > ovs-vsctl show
+   > ovs-vsctl show
    a56ec7b5-5b1f-49ec-a795-79f6eb63228b
        Bridge br-pif
            Port br-pif
@@ -515,46 +516,52 @@  In the example below, we assign a 'OVS port name' called ``ovs-port-a`` to a
 VIF on a VM ``VM1``.  By using index 0 for ``$vnic``, the first VIF of the VM
 is being addressed.  After assigning the name ``ovs-port-a``, the VIF is
 connected back to the Hyper-V switch with name ``OVS-HV-Switch``, which is
-assumed to be the Hyper-V switch with OVS extension enabled.::
-
-    PS > import-module .\datapath-windows\misc\OVS.psm1
-    PS > $vnic = Get-VMNetworkAdapter <Name of the VM>
-    PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0]
-    PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a
-    PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \
-          -SwitchName OVS-Extended-Switch
-
-Next, add the VIFs to ``br-int``::
-
-    PS > ovs-vsctl add-port br-int ovs-port-a
-
-Dumping the ports should show the additional ports that were just added::
-
-    PS > ovs-dpctl show
-    system@ovs-system:
-            lookups: hit:0 missed:0 lost:0
-            flows: 0
-            port 4: ovs-port-a
-            port 2: br-pif (internal)
-            port 1: br-int (internal
-            port 3: Ethernet0
-
-    PS > ovs-vsctl show
-    4cd86499-74df-48bd-a64d-8d115b12a9f2
-        Bridge br-pif
-            Port "vEthernet (external)"
-                Interface "vEthernet (external)"
-            Port "Ethernet0"
-                Interface "Ethernet0"
-            Port br-pif
-                Interface br-pif
-                    type: internal
-        Bridge br-int
-            Port br-int
-                Interface br-int
-                    type: internal
-            Port "ovs-port-a"
-                Interface "ovs-port-a"
+assumed to be the Hyper-V switch with OVS extension enabled.:
+
+.. code-block:: ps1con
+
+   PS > import-module .\datapath-windows\misc\OVS.psm1
+   PS > $vnic = Get-VMNetworkAdapter <Name of the VM>
+   PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0]
+   PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a
+   PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \
+         -SwitchName OVS-Extended-Switch
+
+Next, add the VIFs to ``br-int``:
+
+.. code-block:: doscon
+
+   > ovs-vsctl add-port br-int ovs-port-a
+
+Dumping the ports should show the additional ports that were just added:
+
+.. code-block:: doscon
+
+   > ovs-dpctl show
+   system@ovs-system:
+           lookups: hit:0 missed:0 lost:0
+           flows: 0
+           port 4: ovs-port-a
+           port 2: br-pif (internal)
+           port 1: br-int (internal
+           port 3: Ethernet0
+
+   > ovs-vsctl show
+   4cd86499-74df-48bd-a64d-8d115b12a9f2
+       Bridge br-pif
+           Port "vEthernet (external)"
+               Interface "vEthernet (external)"
+           Port "Ethernet0"
+               Interface "Ethernet0"
+           Port br-pif
+               Interface br-pif
+                   type: internal
+       Bridge br-int
+           Port br-int
+               Interface br-int
+                   type: internal
+           Port "ovs-port-a"
+               Interface "ovs-port-a"
 
 Add multiple NICs to be managed by OVS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -568,7 +575,7 @@  found at technet_.
 For example, to set up a switch team combined from ``Ethernet0 2`` and
 ``Ethernet1 2`` named ``external``:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
    PS > Get-NetAdapter
    Name                      InterfaceDescription
@@ -588,7 +595,7 @@  For example, to set up a switch team combined from ``Ethernet0 2`` and
 
 This will result in a new adapter bound to the host called ``external``:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
    PS > Get-NetAdapter
    Name                      InterfaceDescription
@@ -603,7 +610,7 @@  This will result in a new adapter bound to the host called ``external``:
 
 Next we will set up the Hyper-V VMSwitch on the new adapter ``external``:
 
-.. code-block:: powershell
+.. code-block:: ps1con
 
    PS > New-VMSwitch -Name external -NetAdapterName external \
         -AllowManagementOS $false
@@ -614,10 +621,9 @@  Under OVS the adapters under the team ``external``, ``Ethernet0 2`` and
 The following example shows how the bridges look with the NICs being
 separated:
 
-.. code-block:: powershell
-
-   PS > ovs-vsctl show
+.. code-block:: doscon
 
+   > ovs-vsctl show
    6cd9481b-c249-4ee3-8692-97b399dd29d8
        Bridge br-test
            Port br-test
@@ -640,26 +646,26 @@  Switch VLAN tagging along with patch ports between ``br-int`` and ``br-pif`` is
 used to configure VLAN tagging functionality between two VMs on different
 Hyper-Vs.  To start, add a patch port from ``br-int`` to ``br-pif``:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl add-port br-int patch-to-pif
-   PS > ovs-vsctl set interface patch-to-pif type=patch \
-          options:peer=patch-to-int
+   > ovs-vsctl add-port br-int patch-to-pif
+   > ovs-vsctl set interface patch-to-pif type=patch \
+       options:peer=patch-to-int
 
 Add a patch port from ``br-pif`` to ``br-int``:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl add-port br-pif patch-to-int
-   PS > ovs-vsctl set interface patch-to-int type=patch \
-          options:peer=patch-to-pif
+   > ovs-vsctl add-port br-pif patch-to-int
+   > ovs-vsctl set interface patch-to-int type=patch \
+       options:peer=patch-to-pif
 
 Re-Add the VIF ports with the VLAN tag:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl add-port br-int ovs-port-a tag=900
-   PS > ovs-vsctl add-port br-int ovs-port-b tag=900
+   > ovs-vsctl add-port br-int ovs-port-a tag=900
+   > ovs-vsctl add-port br-int ovs-port-b tag=900
 
 Add tunnels
 ~~~~~~~~~~~
@@ -668,25 +674,25 @@  The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add
 tunnels. For example, first add the tunnel port between 172.168.201.101 <->
 172.168.201.102:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl add-port br-int tun-1
-   PS > ovs-vsctl set Interface tun-1 type=<port-type>
-   PS > ovs-vsctl set Interface tun-1 options:local_ip=172.168.201.101
-   PS > ovs-vsctl set Interface tun-1 options:remote_ip=172.168.201.102
-   PS > ovs-vsctl set Interface tun-1 options:in_key=flow
-   PS > ovs-vsctl set Interface tun-1 options:out_key=flow
+   > ovs-vsctl add-port br-int tun-1
+   > ovs-vsctl set Interface tun-1 type=<port-type>
+   > ovs-vsctl set Interface tun-1 options:local_ip=172.168.201.101
+   > ovs-vsctl set Interface tun-1 options:remote_ip=172.168.201.102
+   > ovs-vsctl set Interface tun-1 options:in_key=flow
+   > ovs-vsctl set Interface tun-1 options:out_key=flow
 
 ...and the tunnel port between 172.168.201.101 <-> 172.168.201.105:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl add-port br-int tun-2
-   PS > ovs-vsctl set Interface tun-2 type=<port-type>
-   PS > ovs-vsctl set Interface tun-2 options:local_ip=172.168.201.102
-   PS > ovs-vsctl set Interface tun-2 options:remote_ip=172.168.201.105
-   PS > ovs-vsctl set Interface tun-2 options:in_key=flow
-   PS > ovs-vsctl set Interface tun-2 options:out_key=flow
+   > ovs-vsctl add-port br-int tun-2
+   > ovs-vsctl set Interface tun-2 type=<port-type>
+   > ovs-vsctl set Interface tun-2 options:local_ip=172.168.201.102
+   > ovs-vsctl set Interface tun-2 options:remote_ip=172.168.201.105
+   > ovs-vsctl set Interface tun-2 options:in_key=flow
+   > ovs-vsctl set Interface tun-2 options:out_key=flow
 
 Where ``<port-type>`` is one of: ``stt`` or ``vxlan``
 
@@ -704,21 +710,21 @@  daemons via ``make install``.
 
 To start, create the database:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovsdb-tool create C:/openvswitch/etc/openvswitch/conf.db \
-          "C:/openvswitch/usr/share/openvswitch/vswitch.ovsschema"
+   > ovsdb-tool create C:/openvswitch/etc/openvswitch/conf.db \
+       "C:/openvswitch/usr/share/openvswitch/vswitch.ovsschema"
 
 Create the ovsdb-server service and start it:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > sc create ovsdb-server \
-          binpath="C:/openvswitch/usr/sbin/ovsdb-server.exe \
-          C:/openvswitch/etc/openvswitch/conf.db \
-          -vfile:info --log-file --pidfile \
-          --remote=punix:db.sock --service --service-monitor"
-   PS > sc start ovsdb-server
+   > sc create ovsdb-server \
+       binpath="C:/openvswitch/usr/sbin/ovsdb-server.exe \
+       C:/openvswitch/etc/openvswitch/conf.db \
+       -vfile:info --log-file --pidfile \
+       --remote=punix:db.sock --service --service-monitor"
+   > sc start ovsdb-server
 
 .. tip::
 
@@ -726,45 +732,45 @@  Create the ovsdb-server service and start it:
    paths.  You can make sure that the correct path has been registered with the
    Windows services manager by running:
 
-   .. code-block:: powershell
+   .. code-block:: doscon
 
-      PS > sc qc ovsdb-server
+      > sc qc ovsdb-server
 
 Check that the service is healthy by running:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > sc query ovsdb-server
+   > sc query ovsdb-server
 
 Initialize the database:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > ovs-vsctl --no-wait init
+   > ovs-vsctl --no-wait init
 
 Create the ovs-vswitchd service and start it:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > sc create ovs-vswitchd \
-        binpath="C:/openvswitch/usr/sbin/ovs-vswitchd.exe \
-        --pidfile -vfile:info --log-file  --service --service-monitor"
-   PS > sc start ovs-vswitchd
+   > sc create ovs-vswitchd \
+       binpath="C:/openvswitch/usr/sbin/ovs-vswitchd.exe \
+       --pidfile -vfile:info --log-file  --service --service-monitor"
+   > sc start ovs-vswitchd
 
 Check that the service is healthy by running:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > sc query ovs-vswitchd
+   > sc query ovs-vswitchd
 
 To stop and delete the services, run:
 
-.. code-block:: powershell
+.. code-block:: doscon
 
-   PS > sc stop ovs-vswitchd
-   PS > sc stop ovsdb-server
-   PS > sc delete ovs-vswitchd
-   PS > sc delete ovsdb-server
+   > sc stop ovs-vswitchd
+   > sc stop ovsdb-server
+   > sc delete ovs-vswitchd
+   > sc delete ovsdb-server
 
 Windows CI Service
 ------------------