Made code block usage consistent across all .md files

README.i18n.md

@@ -15,23 +15,33 @@ You do not need anything from Qt in order to use the final translations.
 
 To update ts files after changing source code:
 
+```bash
 ./utils/translations/update-translations.sh
+```
 
 To add a new language, eg Spanish (ISO code es):
 
+```bash
 cp translations/monero.ts translations/monero_es.ts
+```
 
 To edit translations for Spanish:
 
+```bash
 linguist translations/monero_es.ts
+```
 
 To build translations after modifying them:
 
+```bash
 ./utils/translations/build-translations.sh
+```
 
 To test a translation:
 
+```bash
 LANG=es ./build/release/bin/monero-wallet-cli
+```
 
 To add new translatable strings in the source code:
 
@@ -39,6 +49,8 @@ Use the `tr(string)` function if possible. If the code is in a class, and this c
 
 If you're getting messages of the form:
 
+```
 Class 'cryptonote::simple_wallet' lacks Q_OBJECT macro
+```
 
 all is fine, we don't actually need that here.

README.md

@@ -226,9 +226,11 @@ invokes cmake commands as needed.
 * Install the dependencies
 * Change to the root of the source code directory, change to the most recent release branch, and build:
 
+    ```bash
     cd monero
     git checkout release-v0.14
     make
+    ```
 
     *Optional*: If your machine has several cores and enough memory, enable
     parallel build by running `make -j<number of threads>` instead of `make`. For
@@ -252,23 +254,31 @@ invokes cmake commands as needed.
 
 * **Optional**: build and run the test suite to verify the binaries:
 
+    ```bash
     make release-test
+    ```
 
     *NOTE*: `core_tests` test may take a few hours to complete.
 
 * **Optional**: to build binaries suitable for debugging:
 
+    ```bash
     make debug
+    ```
 
 * **Optional**: to build statically-linked binaries:
 
+    ```bash
     make release-static
+    ```
 
 Dependencies need to be built with -fPIC. Static libraries usually aren't, so you may have to build them yourself with -fPIC. Refer to their documentation for how to build them.
 
 * **Optional**: build documentation in `doc/html` (omit `HAVE_DOT=YES` if `graphviz` is not installed):
 
+    ```bash
     HAVE_DOT=YES doxygen Doxyfile
+    ```
 
 #### On the Raspberry Pi
 
@@ -279,24 +289,30 @@ Tested on a Raspberry Pi Zero with a clean install of minimal Raspbian Stretch (
 * Install the dependencies for Monero from the 'Debian' column in the table above.
 
 * Increase the system swap size:
-```
+
+    ```bash
     sudo /etc/init.d/dphys-swapfile stop  
     sudo nano /etc/dphys-swapfile  
     CONF_SWAPSIZE=2048
     sudo /etc/init.d/dphys-swapfile start
     ```
+
 * If using an external hard disk without an external power supply, ensure it gets enough power to avoid hardware issues when syncing, by adding the line "max_usb_current=1" to /boot/config.txt
 
 * Clone monero and checkout the most recent release version:
-```
+
+    ```bash
     git clone https://github.com/monero-project/monero.git
     cd monero
     git checkout tags/v0.14.1.0
     ```
+
 * Build:
-```
+
+    ```bash
     make release
     ```
+
 * Wait 4-6 hours
 
 * The resulting executables can be found in `build/release/bin`
@@ -313,17 +329,19 @@ If you are using the older Raspbian Jessie image, compiling Monero is a bit more
 
 * As before, `apt-get update && apt-get upgrade` to install all of the latest software, and increase the system swap size
 
-```
+    ```bash
     sudo /etc/init.d/dphys-swapfile stop
     sudo nano /etc/dphys-swapfile
     CONF_SWAPSIZE=2048
     sudo /etc/init.d/dphys-swapfile start
     ```
 
+
 * Then, install the dependencies for Monero except `libunwind` and `libboost-all-dev`
 
 * Install the latest version of boost (this may first require invoking `apt-get remove --purge libboost*` to remove a previous version if you're not using a clean install):
-```
+
+    ```bash
     cd
     wget https://sourceforge.net/projects/boost/files/boost/1.64.0/boost_1_64_0.tar.bz2
     tar xvfo boost_1_64_0.tar.bz2
@@ -331,10 +349,13 @@ If you are using the older Raspbian Jessie image, compiling Monero is a bit more
     ./bootstrap.sh
     sudo ./b2
     ```
+
 * Wait ~8 hours
-```
+
+    ```bash    
     sudo ./bjam cxxflags=-fPIC cflags=-fPIC -a install
     ```
+
 * Wait ~4 hours
 
 * From here, follow the [general Raspberry Pi instructions](#on-the-raspberry-pi) from the "Clone monero and checkout most recent release version" step.
@@ -353,24 +374,32 @@ application.
 * Open the MSYS shell via the `MSYS2 Shell` shortcut
 * Update packages using pacman:  
 
+    ```bash
     pacman -Syu
+    ```
 
 * Exit the MSYS shell using Alt+F4  
 * Edit the properties for the `MSYS2 Shell` shortcut changing "msys2_shell.bat" to "msys2_shell.cmd -mingw64" for 64-bit builds or "msys2_shell.cmd -mingw32" for 32-bit builds
 * Restart MSYS shell via modified shortcut and update packages again using pacman:  
 
+    ```bash
     pacman -Syu
+    ```
 
 
 * Install dependencies:
 
     To build for 64-bit Windows:
 
+    ```bash
     pacman -S mingw-w64-x86_64-toolchain make mingw-w64-x86_64-cmake mingw-w64-x86_64-boost mingw-w64-x86_64-openssl mingw-w64-x86_64-zeromq mingw-w64-x86_64-libsodium mingw-w64-x86_64-hidapi
+    ```
 
     To build for 32-bit Windows:
 
+    ```bash
     pacman -S mingw-w64-i686-toolchain make mingw-w64-i686-cmake mingw-w64-i686-boost mingw-w64-i686-openssl mingw-w64-i686-zeromq mingw-w64-i686-libsodium mingw-w64-i686-hidapi
+    ```
 
 * Open the MingW shell via `MinGW-w64-Win64 Shell` shortcut on 64-bit Windows
   or `MinGW-w64-Win64 Shell` shortcut on 32-bit Windows. Note that if you are
@@ -380,35 +409,49 @@ application.
 
 * To git clone, run:
 
+    ```bash
     git clone --recursive https://github.com/monero-project/monero.git
+    ```
 
 **Building**
 
 * Change to the cloned directory, run:
 
+    ```bash
     cd monero
+    ```
 
 * If you would like a specific [version/tag](https://github.com/monero-project/monero/tags), do a git checkout for that version. eg. 'v0.14.1.0'. If you don't care about the version and just want binaries from master, skip this step:
 	
+    ```bash
     git checkout v0.14.1.0
+    ```
 
 * If you are on a 64-bit system, run:
 
+    ```bash
     make release-static-win64
+    ```
 
 * If you are on a 32-bit system, run:
 
+    ```bash
     make release-static-win32
+    ```
 
 * The resulting executables can be found in `build/release/bin`
 
 * **Optional**: to build Windows binaries suitable for debugging on a 64-bit system, run:
 
+    ```bash
     make debug-static-win64
+    ```
 
 * **Optional**: to build Windows binaries suitable for debugging on a 32-bit system, run:
 
+    ```bash
     make debug-static-win32
+    ```
 
 * The resulting executables can be found in `build/debug/bin`
 
@@ -448,7 +491,7 @@ We assume you are compiling with a non-root user and you have `doas` enabled.
 
 Note: do not use the boost package provided by OpenBSD, as we are installing boost to `/usr/local`.
 
-```
+```bash
 # Create boost building directory
 mkdir ~/boost
 cd ~/boost
@@ -484,7 +527,7 @@ Build the cppzmq bindings.
 
 We assume you are compiling with a non-root user and you have `doas` enabled.
 
-```
+```bash
 # Create cppzmq building directory
 mkdir ~/cppzmq
 cd ~/cppzmq
@@ -504,7 +547,10 @@ cmake ..
 doas make install
 ```
 
-Build monero: `env DEVELOPER_LOCAL_TOOLS=1 BOOST_ROOT=/usr/local make release-static`
+Build monero:
+```bash
+env DEVELOPER_LOCAL_TOOLS=1 BOOST_ROOT=/usr/local make release-static
+```
 
 #### OpenBSD >= 6.4
 
@@ -527,15 +573,18 @@ Then you need to increase the data ulimit size to 2GB and try again: `ulimit -d
 
 The default Solaris linker can't be used, you have to install GNU ld, then run cmake manually with the path to your copy of GNU ld:
 
+```bash
 mkdir -p build/release
 cd build/release
 cmake -DCMAKE_LINKER=/path/to/ld -D CMAKE_BUILD_TYPE=Release ../..
 cd ../..
+```
 
 Then you can run make as usual.
 
 ### On Linux for Android (using docker):
 
+```bash
 # Build image (for ARM 32-bit)
 docker build -f utils/build_scripts/android32.Dockerfile -t monero-android .
 # Build image (for ARM 64-bit)
@@ -544,6 +593,7 @@ Then you can run make as usual.
 docker create -it --name monero-android monero-android bash
 # Get binaries
 docker cp monero-android:/src/build/release/bin .
+```
 
 ### Building portable statically linked binaries
 
@@ -562,12 +612,18 @@ By default, in either dynamically or statically linked builds, binaries target t
 You can also cross-compile static binaries on Linux for Windows and macOS with the `depends` system.
 
 * ```make depends target=x86_64-linux-gnu``` for 64-bit linux binaries.
-* ```make depends target=x86_64-w64-mingw32``` for 64-bit windows binaries. Requires: python3 g++-mingw-w64-x86-64 wine1.6 bc
-* ```make depends target=x86_64-apple-darwin11``` for macOS binaries. Requires: cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python-dev
-* ```make depends target=i686-linux-gnu``` for 32-bit linux binaries. Requires: g++-multilib bc
-* ```make depends target=i686-w64-mingw32``` for 32-bit windows binaries. Requires: python3 g++-mingw-w64-i686
-* ```make depends target=arm-linux-gnueabihf``` for armv7 binaries. Requires: g++-arm-linux-gnueabihf
-* ```make depends target=aarch64-linux-gnu``` for armv8 binaries. Requires: g++-aarch64-linux-gnu
+* ```make depends target=x86_64-w64-mingw32``` for 64-bit windows binaries.
+  * Requires: `python3 g++-mingw-w64-x86-64 wine1.6 bc`
+* ```make depends target=x86_64-apple-darwin11``` for macOS binaries.
+  * Requires: `cmake imagemagick libcap-dev librsvg2-bin libz-dev libbz2-dev libtiff-tools python-dev`
+* ```make depends target=i686-linux-gnu``` for 32-bit linux binaries.
+  * Requires: `g++-multilib bc`
+* ```make depends target=i686-w64-mingw32``` for 32-bit windows binaries.
+  * Requires: `python3 g++-mingw-w64-i686`
+* ```make depends target=arm-linux-gnueabihf``` for armv7 binaries.
+  * Requires: `g++-arm-linux-gnueabihf`
+* ```make depends target=aarch64-linux-gnu``` for armv8 binaries.
+  * Requires: `g++-aarch64-linux-gnu`
 
 The required packages are the names for each toolchain on apt. Depending on your distro, they may have different names.
 
@@ -583,7 +639,9 @@ Packages are available for
 
 * Ubuntu and [snap supported](https://snapcraft.io/docs/core/install) systems, via a community contributed build.
 
+    ```bash
     snap install monero --beta
+    ```
 
 Installing a snap is very quick. Snaps are secure. They are isolated with all of their dependencies. Snaps also auto update when a new version is released.
 
@@ -593,14 +651,19 @@ Installing a snap is very quick. Snaps are secure. They are isolated with all of
 
 * Void Linux:
 
+    ```bash
     xbps-install -S monero
+    ```
 
 * GuixSD
 
+    ```bash
     guix package -i monero
+    ```
 
 * Docker
 
+    ```bash
     # Build using all available cores
     docker build -t monero .
     
@@ -612,6 +675,7 @@ Installing a snap is very quick. Snaps are secure. They are isolated with all of
     
     # or in background
     docker run -it -d -v /monero/chain:/root/.bitmonero -v /monero/wallet:/wallet -p 18080:18080 monero
+    ```
 
 * The build needs 3 GB space.
 * Wait one  hour or more
@@ -624,7 +688,9 @@ The build places the binary in `bin/` sub-directory within the build directory
 from which cmake was invoked (repository root by default). To run in
 foreground:
 
+```bash
 ./bin/monerod
+```
 
 To list all available options, run `./bin/monerod --help`.  Options can be
 specified either on the command line or in a configuration file passed by the
@@ -634,7 +700,9 @@ of the argument without the leading dashes, for example `log-level=1`.
 
 To run in background:
 
+```bash
 ./bin/monerod --log-file monerod.log --detach
+```
 
 To run as a systemd service, copy
 [monerod.service](utils/systemd/monerod.service) to `/etc/systemd/system/` and
@@ -682,7 +750,9 @@ setting the following configuration parameters and environment variables:
 
 Example command line to start monerod through Tor:
 
+```bash
 DNS_PUBLIC=tcp torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd
+```
 
 ### Using Tor on Tails
 
@@ -690,9 +760,11 @@ TAILS ships with a very restrictive set of firewall rules. Therefore, you need
 to add a rule to allow this connection too, in addition to telling torsocks to
 allow inbound connections. Full example:
 
+```bash
 sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 18081 -j ACCEPT
 DNS_PUBLIC=tcp torsocks ./monerod --p2p-bind-ip 127.0.0.1 --no-igd --rpc-bind-ip 127.0.0.1 \
     --data-dir /home/amnesia/Persistent/your/directory/to/the/blockchain
+```
 
 ## Debugging
 
@@ -702,13 +774,13 @@ This section contains general instructions for debugging failed installs or prob
 
 We generally use the tool `gdb` (GNU debugger) to provide stack trace functionality, and `ulimit` to provide core dumps in builds which crash or segfault.
 
-* To use gdb in order to obtain a stack trace for a build that has stalled:
+* To use `gdb` in order to obtain a stack trace for a build that has stalled:
 
 Run the build.
 
 Once it stalls, enter the following command:
 
-```
+```bash
 gdb /path/to/monerod `pidof monerod`
 ```
 
@@ -726,7 +798,9 @@ When it terminates with an output along the lines of "Segmentation fault (core d
 
 You can now analyse this core dump with `gdb` as follows:
 
-`gdb /path/to/monerod /path/to/dumpfile`
+```bash
+gdb /path/to/monerod /path/to/dumpfile`
+```
 
 Print the stack trace with `bt`
 
@@ -746,7 +820,9 @@ There are two tools available:
 
 Configure Monero with the -D SANITIZE=ON cmake flag, eg:
 
+```bash
 cd build/debug && cmake -D SANITIZE=ON -D CMAKE_BUILD_TYPE=Debug ../..
+```
 
 You can then run the monero tools normally. Performance will typically halve.
 
@@ -760,7 +836,9 @@ Instructions for debugging suspected blockchain corruption as per @HYC
 
 There is an `mdb_stat` command in the LMDB source that can print statistics about the database but it's not routinely built. This can be built with the following command:
 
-`cd ~/monero/external/db_drivers/liblmdb && make`
+```bash
+cd ~/monero/external/db_drivers/liblmdb && make
+```
 
 The output of `mdb_stat -ea <path to blockchain dir>` will indicate inconsistencies in the blocks, block_heights and block_info table.
 

contrib/depends/README.md

@@ -2,21 +2,29 @@
 
 To build dependencies for the current arch+OS:
 
+```bash
 make
+```
 
 To build for another arch/OS:
 
+```bash
 make HOST=host-platform-triplet
+```
 
 For example:
 
+```bash
 make HOST=x86_64-w64-mingw32 -j4
+```
 
 A toolchain will be generated that's suitable for plugging into Monero's
 cmake. In the above example, a dir named x86_64-w64-mingw32 will be
 created. To use it for Monero:
 
+```bash
 cmake -DCMAKE_TOOLCHAIN=`pwd`/contrib/depends/x86_64-w64-mingw32
+```
 
 Common `host-platform-triplets` for cross compilation are:
 
@@ -31,6 +39,7 @@ No other options are needed, the paths are automatically configured.
 Dependency Options:
 The following can be set when running make: make FOO=bar
 
+```
 SOURCES_PATH: downloaded sources will be placed here
 BASE_CACHE: built packages will be placed here
 SDK_PATH: Path where sdk's can be found (used by OSX)
@@ -38,13 +47,16 @@ The following can be set when running make: make FOO=bar
 DEBUG: disable some optimizations and enable more runtime checking
 HOST_ID_SALT: Optional salt to use when generating host package ids
 BUILD_ID_SALT: Optional salt to use when generating build package ids
+```
 
 Additional targets:
 
+```
 download: run 'make download' to fetch all sources without building them
 download-osx: run 'make download-osx' to fetch all sources needed for osx builds
 download-win: run 'make download-win' to fetch all sources needed for win builds
 download-linux: run 'make download-linux' to fetch all sources needed for linux builds
+```
 
 #Darwin (macos) builds:
 

contrib/depends/packages.md

@@ -9,6 +9,7 @@ General tips:
 ## Identifiers
 Each package is required to define at least these variables:
 
+```
 $(package)_version:
 Version of the upstream library or program. If there is no version, a
 placeholder such as 1.0 can be used.
@@ -22,9 +23,11 @@ Each package is required to define at least these variables:
 
 $(package)_sha256_hash:
 The sha256 hash of the upstream file
+```
 
 These variables are optional:
 
+```
 $(package)_build_subdir:
 cd to this dir before running configure/build/stage commands.
 
@@ -42,6 +45,7 @@ These variables are optional:
 $(package)_extra_sources:
 Any extra files that will be fetched via $(package)_fetch_cmds. These are
 specified so that they can be fetched and verified via 'make download'.
+```
 
 
 ## Build Variables:
@@ -49,20 +53,25 @@ After defining the main identifiers, build variables may be added or customized
 before running the build commands. They should be added to a function called
 $(package)_set_vars. For example:
 
+```
 define $(package)_set_vars
 ...
 endef
+```
 
 Most variables can be prefixed with the host, architecture, or both, to make
 the modifications specific to that case. For example:
 
+```
 Universal:     $(package)_cc=gcc
 Linux only:    $(package)_linux_cc=gcc
 x86_64 only:       $(package)_x86_64_cc = gcc
 x86_64 linux only: $(package)_x86_64_linux_cc = gcc
+```
 
 These variables may be set to override or append their default values.
 
+```
 $(package)_cc
 $(package)_cxx
 $(package)_objc
@@ -80,16 +89,19 @@ These variables may be set to override or append their default values.
 $(package)_stage_env
 $(package)_build_opts
 $(package)_config_opts
+```
 
-The *_env variables are used to add environment variables to the respective
+The `*_env` variables are used to add environment variables to the respective
 commands.
 
 Many variables respect a debug/release suffix as well, in order to use them for
 only the appropriate build config. For example:
 
+```
 $(package)_cflags_release = -O3
 $(package)_cflags_i686_debug = -g
 $(package)_config_opts_release = --disable-debug
+```
 
 These will be used in addition to the options that do not specify
 debug/release. All builds are considered to be release unless DEBUG=1 is set by
@@ -102,6 +114,7 @@ the user. Other variables may be defined as needed.
 
 The following build commands are available for each recipe:
 
+```
 $(package)_fetch_cmds:
 Runs from: build dir
 Fetch the source file. If undefined, it will be fetched and verified
@@ -127,21 +140,26 @@ the user. Other variables may be defined as needed.
 $(package)_stage_cmds:
 Runs from: build dir/$(package)_build_subdir
 Stage the build results. If undefined, does nothing.
+```
 
 The following variables are available for each recipe:
 
+```    
 $(1)_staging_dir: package's destination sysroot path
 $(1)_staging_prefix_dir: prefix path inside of the package's staging dir
 $(1)_extract_dir: path to the package's extracted sources
 $(1)_build_dir: path where configure/build/stage commands will be run
 $(1)_patch_dir: path where the package's patches (if any) are found
+```
 
 Notes on build commands:
 
-For packages built with autotools, $($(package)_autoconf) can be used in the
+For packages built with autotools, `$($(package)_autoconf)` can be used in the
 configure step to (usually) correctly configure automatically. Any
-$($(package)_config_opts) will be appended.
+`$($(package)_config_opts`) will be appended.
 
 Most autotools projects can be properly staged using:
 
+```bash
 $(MAKE) DESTDIR=$($(package)_staging_dir) install
+```

contrib/gitian/README.md

@@ -119,7 +119,7 @@ In order to sign gitian builds on your host machine, which has your PGP key,
 fork the gitian.sigs repository and clone it on your host machine, 
 or pass the signed assert file back to your build machine.
 
-```
+```bash
 git clone git@github.com:monero-project/gitian.sigs.git
 git remote add fluffypony git@github.com:fluffypony/gitian.sigs.git
 ```

src/blockchain_utilities/README.md

@@ -79,7 +79,7 @@ LMDB flags (more than one may be specified):
 
 ## Examples:
 
-```
+```bash
 $ monero-blockchain-import --database lmdb#fastest
 
 $ monero-blockchain-import --database lmdb#nosync

tests/README.md

@@ -2,7 +2,7 @@
 
 To run all tests, run:
 
-```
+```bash
 cd /path/to/monero
 make [-jn] debug-test # where n is number of compiler processes
 ```
@@ -17,7 +17,7 @@ Tests are located in `tests/core_tests/`, and follow a straightforward naming co
 
 To run only Monero's core tests (after building):
 
-```
+```bash
 cd build/debug/tests/core_tests
 ctest
 ```
@@ -36,7 +36,7 @@ Tests correspond to components under `src/crypto/`. A quick comparison reveals t
 
 To run only Monero's crypto tests (after building):
 
-```
+```bash
 cd build/debug/tests/crypto
 ctest
 ```
@@ -53,13 +53,13 @@ To run the same tests on a release build, replace `debug` with `release`.
 Functional tests are located under the `tests/functional` directory.
 
 First, run a regtest daemon in the offline mode and with a fixed difficulty:
-```
+```bash
 monerod --regtest --offline --fixed-difficulty 1
 ```
 Alternatively, you can run multiple daemons and let them connect with each other by using `--add-exclusive-node`. In this case, make sure that the same fixed difficulty is given to all the daemons.
 
 Next, restore a mainnet wallet with the following seed and restore height 0 (the file path doesn't matter):
-```
+```bash
 velvet lymph giddy number token physics poetry unquoted nibs useful sabotage limits benches lifestyle eden nitrogen anvil fewest avoid batch vials washing fences goat unquoted
 ```
 
@@ -77,7 +77,7 @@ Hash tests exist under `tests/hash`, and include a set of target hashes in text
 
 To run only Monero's hash tests (after building):
 
-```
+```bash
 cd build/debug/tests/hash
 ctest
 ```
@@ -98,7 +98,7 @@ Performance tests are located in `tests/performance_tests`, and test features fo
 
 To run only Monero's performance tests (after building):
 
-```
+```bash
 cd build/debug/tests/performance_tests
 ./performance_tests
 ```
@@ -115,7 +115,7 @@ Unit tests are defined under the `tests/unit_tests` directory. Independent compo
 
 To run only Monero's unit tests (after building):
 
-```
+```bash
 cd build/debug/tests/unit_tests
 ctest
 ```

tests/gtest/README.md

@@ -14,15 +14,19 @@ Suppose you put Google Test in directory `${GTEST_DIR}`.  To build it,
 create a library build target (or a project as called by Visual Studio
 and Xcode) to compile
 
+```bash
 ${GTEST_DIR}/src/gtest-all.cc
+```
 
 with `${GTEST_DIR}/include` in the system header search path and `${GTEST_DIR}`
 in the normal header search path.  Assuming a Linux-like system and gcc,
 something like the following will do:
 
+```bash
 g++ -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \
     -pthread -c ${GTEST_DIR}/src/gtest-all.cc
 ar -rv libgtest.a gtest-all.o
+```
 
 (We need `-pthread` as Google Test uses threads.)
 
@@ -30,8 +34,10 @@ Next, you should compile your test source file with
 `${GTEST_DIR}/include` in the system header search path, and link it
 with gtest and any other necessary libraries:
 
+```bash
 g++ -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \
     -o your_test
+```
 
 As an example, the make/ directory contains a Makefile that you can
 use to build Google Test on systems where GNU make is available
@@ -43,9 +49,11 @@ script.
 If the default settings are correct for your environment, the
 following commands should succeed:
 
+```bash
 cd ${GTEST_DIR}/make
 make
 ./sample1_unittest
+```
 
 If you see errors, try to tweak the contents of `make/Makefile` to make
 them go away.  There are instructions in `make/Makefile` on how to do
@@ -62,14 +70,18 @@ CMake works by generating native makefiles or build projects that can
 be used in the compiler environment of your choice.  The typical
 workflow starts with:
 
+```bash
 mkdir mybuild       # Create a directory to hold the build output.
 cd mybuild
 cmake ${GTEST_DIR}  # Generate native build scripts.
+```
 
 If you want to build Google Test's samples, you should replace the
 last command with
 
+```bash
 cmake -Dgtest_build_samples=ON ${GTEST_DIR}
+```
 
 If you are on a \*nix system, you should now see a Makefile in the
 current directory.  Just type 'make' to build gtest.
@@ -108,7 +120,9 @@ end up in your selected build directory (selected in the Xcode
 "Preferences..." -> "Building" pane and defaults to xcode/build).
 Alternatively, at the command line, enter:
 
+```bash
 xcodebuild
+```
 
 This will build the "Release" configuration of gtest.framework in your
 default build location.  See the "xcodebuild" man page for more
@@ -152,18 +166,24 @@ tell Google Test to use the same TR1 tuple library the rest of your
 project uses, or the two tuple implementations will clash.  To do
 that, add
 
+```bash
 -DGTEST_USE_OWN_TR1_TUPLE=0
+```
 
 to the compiler flags while compiling Google Test and your tests.  If
 you want to force Google Test to use its own tuple library, just add
 
+```bash
 -DGTEST_USE_OWN_TR1_TUPLE=1
+```
 
 to the compiler flags instead.
 
 If you don't want Google Test to use tuple at all, add
 
+```bash
 -DGTEST_HAS_TR1_TUPLE=0
+```
 
 and all features using tuple will be disabled.
 
@@ -177,11 +197,15 @@ macro to see whether this is the case (yes if the macro is `#defined` to
 If Google Test doesn't correctly detect whether pthread is available
 in your environment, you can force it with
 
+```bash
 -DGTEST_HAS_PTHREAD=1
+```
 
 or
 
+```bash
 -DGTEST_HAS_PTHREAD=0
+```
 
 When Google Test uses pthread, you may need to add flags to your
 compiler and/or linker to select the pthread library, or you'll get
@@ -198,7 +222,9 @@ as a shared library (known as a DLL on Windows) if you prefer.
 
 To compile *gtest* as a shared library, add
 
+```bash
 -DGTEST_CREATE_SHARED_LIBRARY=1
+```
 
 to the compiler flags.  You'll also need to tell the linker to produce
 a shared library instead - consult your linker's manual for how to do
@@ -206,7 +232,9 @@ it.
 
 To compile your *tests* that use the gtest shared library, add
 
+```bash
 -DGTEST_LINKED_AS_SHARED_LIBRARY=1
+```
 
 to the compiler flags.
 
@@ -229,18 +257,24 @@ conflict.
 Specifically, if both Google Test and some other code define macro
 FOO, you can add
 
+```bash
 -DGTEST_DONT_DEFINE_FOO=1
+```
 
 to the compiler flags to tell Google Test to change the macro's name
 from `FOO` to `GTEST_FOO`.  Currently `FOO` can be `FAIL`, `SUCCEED`,
 or `TEST`.  For example, with `-DGTEST_DONT_DEFINE_TEST=1`, you'll
 need to write
 
+```c++
 GTEST_TEST(SomeTest, DoesThis) { ... }
+```
 
 instead of
 
+```c++
 TEST(SomeTest, DoesThis) { ... }
+```
 
 in order to define a test.
 
@@ -254,9 +288,11 @@ To make sure your changes work as intended and don't break existing
 functionality, you'll want to compile and run Google Test's own tests.
 For that you can use CMake:
 
+```bash
 mkdir mybuild
 cd mybuild
 cmake -Dgtest_build_tests=ON ${GTEST_DIR}
+```
 
 Make sure you have Python installed, as some of Google Test's tests
 are written in Python.  If the cmake command complains about not being
@@ -264,12 +300,16 @@ able to find Python (`Could NOT find PythonInterp (missing:
 PYTHON_EXECUTABLE)`), try telling it explicitly where your Python
 executable can be found:
 
+```bash
 cmake -DPYTHON_EXECUTABLE=path/to/python -Dgtest_build_tests=ON ${GTEST_DIR}
+```
 
 Next, you can build Google Test and all of its own tests.  On \*nix,
 this is usually done by 'make'.  To run the tests, do
 
+```bash
 make test
+```
 
 All tests should pass.