merge #4507 into opencontainers/runc:release-1.2

Akihiro Suda (1):
  docs: remove prompt symbols from shell snippets

LGTMs: AkihiroSuda cyphar

contrib/cmd/memfd-bind/README.md

@@ -24,8 +24,8 @@ but for most users the security benefit is identical.
 The provided `memfd-bind@.service` file can be used to get systemd to manage
 this daemon. You can supply the path like so:
 
-```
-% systemctl start memfd-bind@$(systemd-escape -p /usr/bin/runc)
+```bash
+systemctl start memfd-bind@$(systemd-escape -p /usr/bin/runc)
 ```
 
 Thus, there are three ways of protecting against CVE-2019-5736, in order of how

docs/cgroup-v2.md

@@ -34,18 +34,18 @@ The recommended systemd version is 244 or later. Older systemd does not support
 
 Make sure you also have the `dbus-user-session` (Debian/Ubuntu) or `dbus-daemon` (CentOS/Fedora) package installed, and that `dbus` is running. On Debian-flavored distros, this can be accomplished like so:
 
-```console
-$ sudo apt install -y dbus-user-session
-$ systemctl --user start dbus
+```bash
+sudo apt install -y dbus-user-session
+systemctl --user start dbus
 ```
 
 ## Rootless
 On cgroup v2 hosts, rootless runc can talk to systemd to get cgroup permissions to be delegated.
 
-```console
-$ runc spec --rootless
-$ jq '.linux.cgroupsPath="user.slice:runc:foo"' config.json | sponge config.json
-$ runc --systemd-cgroup run foo
+```bash
+runc spec --rootless
+jq '.linux.cgroupsPath="user.slice:runc:foo"' config.json | sponge config.json
+runc --systemd-cgroup run foo
 ```
 
 The container processes are executed in a cgroup like `/user.slice/user-$(id -u).slice/user@$(id -u).service/user.slice/runc-foo.scope`.
@@ -60,11 +60,11 @@ memory pids
 
 To allow delegation of other controllers, you need to change the systemd configuration as follows:
 
-```console
-# mkdir -p /etc/systemd/system/user@.service.d
-# cat > /etc/systemd/system/user@.service.d/delegate.conf << EOF
+```bash
+sudo mkdir -p /etc/systemd/system/user@.service.d
+cat <<EOF | sudo tee /etc/systemd/system/user@.service.d/delegate.conf
 [Service]
 Delegate=cpu cpuset io memory pids
 EOF
-# systemctl daemon-reload
+sudo systemctl daemon-reload
 ```

docs/terminals.md

@@ -35,8 +35,8 @@ descriptors to preserve. Instead, it takes how many file descriptors (not
 including `stdio` or `LISTEN_FDS`) should be passed to the container. In the
 following example:
 
-```
-% runc run --preserve-fds 5 <container>
+```bash
+runc run --preserve-fds 5 <container>
 ```
 
 `runc` will pass the first `5` file descriptors (`3`, `4`, `5`, `6`, and `7` --
@@ -46,8 +46,8 @@ In addition to `--preserve-fds`, `LISTEN_FDS` file descriptors are passed
 automatically to allow for `systemd`-style socket activation. To extend the
 above example:
 
-```
-% LISTEN_PID=$pid_of_runc LISTEN_FDS=3 runc run --preserve-fds 5 <container>
+```bash
+LISTEN_PID=$pid_of_runc LISTEN_FDS=3 runc run --preserve-fds 5 <container>
 ```
 
 `runc` will now pass the first `8` file descriptors (and it will also pass
@@ -136,8 +136,8 @@ not a terminal (some `ssh` implementations only look for a terminal on stdin).
 
 Another way is to run runc under the `script` utility, like this
 
-```console
-$ script -e -c 'runc run <container>'
+```bash
+script -e -c 'runc run <container>'
 ```
 
 [tty_ioctl(4)]: https://linux.die.net/man/4/tty_ioctl
@@ -150,8 +150,8 @@ the contained process (this is not necessarily the same as `--preserve-fds`'s
 passing of file descriptors -- [details below](#runc-modes)). As an example
 (assuming that `terminal: false` is set in `config.json`):
 
-```
-% echo input | runc run some_container > /tmp/log.out 2> /tmp/log.err
+```bash
+echo input | runc run some_container > /tmp/log.out 2> /tmp/log.err
 ```
 
 Here the container's various `stdio` file descriptors will be substituted with

tests/integration/README.md

@@ -15,20 +15,20 @@ framework.
 ## Running integration tests
 
 The easiest way to run integration tests is with Docker:
-```
-$ make integration
+```bash
+make integration
 ```
 Alternatively, you can run integration tests directly on your host through make:
-```
-$ sudo make localintegration
+```bash
+sudo make localintegration
 ```
 Or you can just run them directly using bats
-```
-$ sudo bats tests/integration
+```bash
+sudo bats tests/integration
 ```
 To run a single test bucket:
-```
-$ make integration TESTPATH="/checkpoint.bats"
+```bash
+make integration TESTPATH="/checkpoint.bats"
 ```
 
 
@@ -36,11 +36,11 @@ To run them on your host, you need to set up a development environment plus
 [bats (Bash Automated Testing System)](https://github.com/bats-core/bats-core#installing-bats-from-source).
 
 For example:
-```
-$ cd ~/go/src/github.com
-$ git clone https://github.com/bats-core/bats-core.git
-$ cd bats-core
-$ ./install.sh /usr/local
+```bash
+cd ~/go/src/github.com
+git clone https://github.com/bats-core/bats-core.git
+cd bats-core
+./install.sh /usr/local
 ```
 
 > **Note**: There are known issues running the integration tests using