Use console lexer instead of bash with a prompt

developer/building/development-workflow.rst

@@ -17,7 +17,7 @@ The best way to write and contribute code is to create a git repo somewhere (e.g
 
 **Example:**
 
-.. code:: bash
+.. code:: console
 
       $ cd qubes-builder/artifacts/sources/qubes-manager
       $ git remote add abel git@GitHub.com:abeluck/qubes-manager.git
@@ -290,7 +290,7 @@ You will also need to setup qrexec policy in dom0 (``/etc/qubes-rpc/policy/local
 
 Usage:
 
-.. code:: bash
+.. code:: console
 
       [user@source core-agent-linux]$ git remote add testbuilder "ext::git-qrexec testbuilder 3 core-agent-linux"
       [user@source core-agent-linux]$ git push testbuilder master

developer/building/qubes-builder-v2.rst

@@ -31,7 +31,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
 
 
 
-   .. code:: bash
+   .. code:: console
 
          $ sudo dnf install $(cat dependencies-fedora.txt)
          $ test -f /usr/share/qubes/marker-vm && sudo dnf install qubes-gpg-split
@@ -43,7 +43,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
 
 
 
-   .. code:: bash
+   .. code:: console
 
          $ sudo apt install $(cat dependencies-debian.txt)
          $ test -f /usr/share/qubes/marker-vm && sudo apt install qubes-gpg-split
@@ -60,7 +60,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
 
 4. If you haven’t previously used docker in the current qube, you need to set up some permissions. In particular, the user has to be added to the ``docker`` group:
 
-   .. code:: bash
+   .. code:: console
 
          $ sudo usermod -aG docker user
 
@@ -68,7 +68,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
 
 5. Finally, you need to generate a docker image:
 
-   .. code:: bash
+   .. code:: console
 
          $ tools/generate-container-image.sh docker
 
@@ -124,7 +124,7 @@ Using Builder v2
 
 To fetch sources - in this example, for the ``core-admin-client`` package, you can use the following command:
 
-.. code:: bash
+.. code:: console
 
       $ ./qb -c core-admin-client package fetch
 
@@ -133,21 +133,21 @@ This will fetch the sources for the listed package and place them in ``artifacts
 
 To build a package (from sources in the ``artifacts/sources`` directory), use:
 
-.. code:: bash
+.. code:: console
 
       $ ./qb -c core-admin-client package fetch prep build
 
 
 or, if you want to build for a specific target (``host-fc37`` is a ``dom0`` using Fedora 37, ``vm-fc40`` would be a qube using Fedora 40 etc.), use:
 
-.. code:: bash
+.. code:: console
 
       $ ./qb -c core-admin-client -d host-fc37 package fetch prep build
 
 
 If you want to fetch the entire Qubes OS source use the following:
 
-.. code:: bash
+.. code:: console
 
       $ ./qb package fetch
 

developer/building/qubes-iso-building.rst

@@ -32,7 +32,7 @@ Create a standalone AppVM from the Fedora template. Set private storage to at le
 
 Once you’ve built the development AppVM, open a Terminal window to it and install the necessary dependencies (see :doc:`QubesBuilder </developer/building/qubes-builder>` for more info):
 
-.. code:: bash
+.. code:: console
 
       $ sudo dnf install git createrepo rpm-build rpm-sign make python3-sh rpmdevtools rpm-sign dialog perl-open python3-pyyaml perl-Digest-MD5 perl-Digest-SHA
 

developer/code/code-signing.rst

@@ -13,7 +13,7 @@ Generating a Key
 
 Alex Cabal has written an excellent `guide <https://alexcabal.com/creating-the-perfect-gpg-keypair/>`__ on creating a PGP keypair. Below, we reproduce just the minimum steps in generating a keypair using GnuPG. Please read Cabal’s full guide for further important details.
 
-.. code:: bash
+.. code:: console
 
       $ gpg --gen-key
       gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
@@ -75,7 +75,7 @@ Replace 6E2F4E7AF50A5827 with your key ID, preferably the **long keyID** which i
 
 
 
-.. code:: bash
+.. code:: console
 
       $ gpg --send-keys --keyserver hkps://keyserver.ubuntu.com 6E2F4E7AF50A5827
       gpg: sending key 6E2F4E7AF50A5827 to hkps://keyserver.ubuntu.com

developer/debugging/automated-tests.rst

@@ -39,7 +39,7 @@ Our test runner runs mostly the same as the standard one, but it has some nice a
 
 You can use ``python3 -m qubes.tests.run -h`` to get usage information:
 
-.. code:: bash
+.. code:: console
 
       [user@dom0 ~]$ python3 -m qubes.tests.run -h
       usage: run.py [-h] [--verbose] [--quiet] [--list] [--failfast] [--no-failfast]
@@ -82,7 +82,7 @@ You can use ``python3 -m qubes.tests.run -h`` to get usage information:
 
 For instance, to run only the tests for the fedora-21 template, you can use the ``-l`` option, then filter the list:
 
-.. code:: bash
+.. code:: console
 
       [user@dom0 ~]$ python3 -m qubes.tests.run -l | grep fedora-21
       network/VmNetworking_fedora-21/test_000_simple_networking

developer/debugging/mount-lvm-image.rst

@@ -7,7 +7,7 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
 
 1: make the image available for qubesdb. From dom0 terminal:
 
-.. code:: bash
+.. code:: console
 
       # Example: /dev/qubes_dom0/vm-debian-9-tmp-root
       [user@dom0]$ dev=$(basename $(readlink /dev/YOUR_LVM_VG/YOUR_LVM_IMAGE))
@@ -16,7 +16,7 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
 
 2: Create a new disposable VM
 
-.. code:: bash
+.. code:: console
 
       [user@dom0]$ qvm-run -v --dispvm=YOUR_DVM_TEMPLATE --service qubes.StartApp+xterm &
 
@@ -25,28 +25,28 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
 
 From the GUI, or from the command line:
 
-.. code:: bash
+.. code:: console
 
       [user@dom0]$ qvm-block attach NEWLY_CREATED_DISPVM dom0:$dev
 
 
 4: Mount the partition you want to, and do what you want with it
 
-.. code:: bash
+.. code:: console
 
       [user@dispXXXX]$ mount /dev/xvdiX /mnt/
 
 
 5: Umount and kill the VM
 
-.. code:: bash
+.. code:: console
 
       [user@dispXXXX]$ umount /mnt/
 
 
 6: Remove the image from qubesdb
 
-.. code:: bash
+.. code:: console
 
       [user@dom0]$ qubesdb-rm /qubes-block-devices/$dev/
 

developer/debugging/safe-remote-ttys.rst

@@ -17,7 +17,7 @@ To a different VM
 
 As an example of forwarding terminal output to another VM on the same machine:
 
-.. code:: bash
+.. code:: console
 
       $ mkfifo /tmp/foo
       $ qvm-run -p some-vm 'xterm -e "cat 0<&5" 5<&0' </tmp/foo >/dev/null 2>&1 &
@@ -31,7 +31,7 @@ To a different machine
 
 In this case over SSH (from a network-connected VM):
 
-.. code:: bash
+.. code:: console
 
       $ mkfifo /tmp/foo
       $ qvm-run -p some-vm \
@@ -55,7 +55,7 @@ Terminal size
 
 It is up to you to ensure the sizes of the local and remote terminal are the same, otherwise things may display incorrectly (especially in interactive programs). Depending on your shell, the size of your local (blind) terminal is likely stored in the ``$LINES`` and ``$COLUMNS`` variables.
 
-.. code:: bash
+.. code:: console
 
       $ echo $COLUMNS $LINES
       80 24

developer/services/qrexec.rst

@@ -20,7 +20,7 @@ Qrexec is built on top of *vchan*, a Xen library providing data links between VM
 
 The ``qrexec-client`` command is used to make connections to VMs from dom0. For example, the following command creates an empty file called ``hello-world.txt`` in the home folder of ``someVM``:
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client -e -d someVM user:'touch hello-world.txt'
 
@@ -28,7 +28,7 @@ The ``qrexec-client`` command is used to make connections to VMs from dom0. For
 
 The string before the colon specifies which user will run the command. The ``-e`` flag tells ``qrexec-client`` to exit immediately after sending the execution request and receiving a status code from ``qrexec-agent`` (if the process creation succeeded). With this option, no further data is passed between the domains. The following command demonstrates an open channel between dom0 and someVM (in this case, a remote shell):
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client -d someVM user:bash
 
@@ -85,7 +85,7 @@ Making an RPC call
 
 From outside of dom0, RPC calls take the following form:
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client-vm target_vm_name RPC_ACTION_NAME rpc_client_path client arguments
 
@@ -93,7 +93,7 @@ From outside of dom0, RPC calls take the following form:
 
 For example:
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client-vm work qubes.StartApp+firefox
 
@@ -103,7 +103,7 @@ Note that only stdin/stdout is passed between RPC server and client – notably,
 
 It is also possible to call service without specific client program – in which case server stdin/out will be connected with the terminal:
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client-vm target_vm_name RPC_ACTION_NAME
 
@@ -167,7 +167,7 @@ Be very careful when coding and adding a new RPC service. Unless the offered fun
 
 For example, this command will run the ``firefox`` command in a DisposableVM based on ``work``:
 
-.. code:: bash
+.. code:: console
 
       $ qvm-run --dispvm=work firefox
 
@@ -175,7 +175,7 @@ For example, this command will run the ``firefox`` command in a DisposableVM bas
 
 By contrast, consider this command:
 
-.. code:: bash
+.. code:: console
 
       $ qvm-run --dispvm=work --service qubes.StartApp+firefox
 
@@ -203,7 +203,7 @@ The argument is specified in the second column of the policy line, as +ARGUMENT.
 
 When calling a service that takes an argument, just add the argument to the service name separated with ``+``.
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client-vm target_vm_name RPC_ACTION_NAME+ARGUMENT
 
@@ -263,7 +263,7 @@ This will allow our client and server to communicate.
 
 Before we make the call, ensure that the client and server scripts have executable permissions. Finally, invoke the RPC service.
 
-.. code:: bash
+.. code:: console
 
       $ qrexec-client-vm anotherVM test.Add /usr/bin/our_test_add_client 1 2
 
@@ -309,7 +309,7 @@ Now we create the policy file in dom0, at ``/etc/qubes/policy.d/30-test.policy``
 
 With this done, we can run some tests. Invoke RPC from ``source_vm1`` via
 
-.. code:: bash
+.. code:: console
 
       [user@source_vm1] $ qrexec-client-vm target_vm test.File+testfile1
 
@@ -317,7 +317,7 @@ With this done, we can run some tests. Invoke RPC from ``source_vm1`` via
 
 We should get the contents of ``/home/user/testfile1`` printed to the terminal. Invoking the service from ``source_vm2`` should result in a denial, but ``testfile2`` should work.
 
-.. code:: bash
+.. code:: console
 
       [user@source_vm2] $ qrexec-client-vm target_vm test.File+testfile1
       Request refused

developer/services/qrexec2.rst

@@ -17,7 +17,7 @@ Typically, the first thing that a ``qrexec-client`` instance does is to send a r
 
 E.g., to start a primitive shell in a VM type the following in Dom0 console:
 
-.. code:: bash
+.. code:: console
 
       [user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
 
@@ -147,7 +147,7 @@ We will show the necessary files to create a simple RPC call that adds two integ
 
 - Policy file in dom0 (``/etc/qubes-rpc/policy/test.Add``)
 
-  .. code:: bash
+  .. code::
 
         $anyvm $anyvm ask