Enable syntax highlighting

8 files changed, 195 insertions, 105 deletions

diff --git a/doc/manual/src/package-management/basic-package-mgmt.md b/doc/manual/src/package-management/basic-package-mgmt.md
index 17b5cc9c2..9702a29eb 100644
--- a/doc/manual/src/package-management/basic-package-mgmt.md
+++ b/doc/manual/src/package-management/basic-package-mgmt.md
@@ -31,8 +31,10 @@ automatically added to your list of “subscribed” channels when you
 install Nix. If this is not the case for some reason, you can add it
 as follows:
 
-    $ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
-    $ nix-channel --update
+```console
+$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
+$ nix-channel --update
+```
 
 > **Note**
 > 
@@ -44,14 +46,16 @@ as follows:
 
 You can view the set of available packages in Nixpkgs:
 
-    $ nix-env -qa
-    aterm-2.2
-    bash-3.0
-    binutils-2.15
-    bison-1.875d
-    blackdown-1.4.2
-    bzip2-1.0.2
-    …
+```console
+$ nix-env -qa
+aterm-2.2
+bash-3.0
+binutils-2.15
+bison-1.875d
+blackdown-1.4.2
+bzip2-1.0.2
+…
+```
 
 The flag `-q` specifies a query operation, and `-a` means that you want
 to show the “available” (i.e., installable) packages, as opposed to the
@@ -59,31 +63,39 @@ installed packages. If you downloaded Nixpkgs yourself, or if you
 checked it out from GitHub, then you need to pass the path to your
 Nixpkgs tree using the `-f` flag:
 
-    $ nix-env -qaf /path/to/nixpkgs
+```console
+$ nix-env -qaf /path/to/nixpkgs
+```
 
 where */path/to/nixpkgs* is where you’ve unpacked or checked out
 Nixpkgs.
 
 You can select specific packages by name:
 
-    $ nix-env -qa firefox
-    firefox-34.0.5
-    firefox-with-plugins-34.0.5
+```console
+$ nix-env -qa firefox
+firefox-34.0.5
+firefox-with-plugins-34.0.5
+```
 
 and using regular expressions:
 
-    $ nix-env -qa 'firefox.*'
+```console
+$ nix-env -qa 'firefox.*'
+```
 
 It is also possible to see the *status* of available packages, i.e.,
 whether they are installed into the user environment and/or present in
 the system:
 
-    $ nix-env -qas
-    …
-    -PS bash-3.0
-    --S binutils-2.15
-    IPS bison-1.875d
-    …
+```console
+$ nix-env -qas
+…
+-PS bash-3.0
+--S binutils-2.15
+IPS bison-1.875d
+…
+```
 
 The first character (`I`) indicates whether the package is installed in
 your current user environment. The second (`P`) indicates whether it is
@@ -96,7 +108,9 @@ Nix knows that it can fetch a pre-built package from somewhere
 
 You can install a package using `nix-env -i`. For instance,
 
-    $ nix-env -i subversion
+```console
+$ nix-env -i subversion
+```
 
 will install the package called `subversion` (which is, of course, the
 [Subversion version management system](http://subversion.tigris.org/)).
@@ -121,12 +135,16 @@ will install the package called `subversion` (which is, of course, the
 
 Naturally, packages can also be uninstalled:
 
-    $ nix-env -e subversion
+```console
+$ nix-env -e subversion
+```
 
 Upgrading to a new version is just as easy. If you have a new release of
 Nix Packages, you can do:
 
-    $ nix-env -u subversion
+```console
+$ nix-env -u subversion
+```
 
 This will *only* upgrade Subversion if there is a “newer” version in the
 new set of Nix expressions, as defined by some pretty arbitrary rules
@@ -137,14 +155,18 @@ whatever version is in the Nix expressions, use `-i` instead of `-u`;
 
 You can also upgrade all packages for which there are newer versions:
 
-    $ nix-env -u
+```console
+$ nix-env -u
+```
 
 Sometimes it’s useful to be able to ask what `nix-env` would do, without
 actually doing it. For instance, to find out what packages would be
 upgraded by `nix-env -u`, you can do
 
-    $ nix-env -u --dry-run
-    (dry run; not doing anything)
-    upgrading `libxslt-1.1.0' to `libxslt-1.1.10'
-    upgrading `graphviz-1.10' to `graphviz-1.12'
-    upgrading `coreutils-5.0' to `coreutils-5.2.1'
+```console
+$ nix-env -u --dry-run
+(dry run; not doing anything)
+upgrading `libxslt-1.1.0' to `libxslt-1.1.10'
+upgrading `graphviz-1.10' to `graphviz-1.12'
+upgrading `coreutils-5.0' to `coreutils-5.2.1'
+```
diff --git a/doc/manual/src/package-management/binary-cache-substituter.md b/doc/manual/src/package-management/binary-cache-substituter.md
index 44f0da238..bdc5038fc 100644
--- a/doc/manual/src/package-management/binary-cache-substituter.md
+++ b/doc/manual/src/package-management/binary-cache-substituter.md
@@ -8,16 +8,22 @@ usually uses to fetch pre-built binaries from <https://cache.nixos.org>.
 The daemon that handles binary cache requests via HTTP, `nix-serve`, is
 not part of the Nix distribution, but you can install it from Nixpkgs:
 
-    $ nix-env -i nix-serve
+```console
+$ nix-env -i nix-serve
+```
 
 You can then start the server, listening for HTTP connections on
 whatever port you like:
 
-    $ nix-serve -p 8080
+```console
+$ nix-serve -p 8080
+```
 
 To check whether it works, try the following on the client:
 
-    $ curl http://avalon:8080/nix-cache-info
+```console
+$ curl http://avalon:8080/nix-cache-info
+```
 
 which should print something like:
 
@@ -28,7 +34,9 @@ which should print something like:
 On the client side, you can tell Nix to use your binary cache using
 `--option extra-binary-caches`, e.g.:
 
-    $ nix-env -i firefox --option extra-binary-caches http://avalon:8080/
+```console
+$ nix-env -i firefox --option extra-binary-caches http://avalon:8080/
+```
 
 The option `extra-binary-caches` tells Nix to use this binary cache in
 addition to your default caches, such as <https://cache.nixos.org>.
diff --git a/doc/manual/src/package-management/channels.md b/doc/manual/src/package-management/channels.md
index c239998d9..93c8b41a6 100644
--- a/doc/manual/src/package-management/channels.md
+++ b/doc/manual/src/package-management/channels.md
@@ -15,7 +15,9 @@ To see the list of official NixOS channels, visit
 
 You can “subscribe” to a channel using `nix-channel --add`, e.g.,
 
-    $ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
+```console
+$ nix-channel --add https://nixos.org/channels/nixpkgs-unstable
+```
 
 subscribes you to a channel that always contains that latest version of
 the Nix Packages collection. (Subscribing really just means that the URL
@@ -24,11 +26,15 @@ calls to `nix-channel
 --update`.) You can “unsubscribe” using `nix-channel
 --remove`:
 
-    $ nix-channel --remove nixpkgs
+```console
+$ nix-channel --remove nixpkgs
+```
 
 To obtain the latest Nix expressions available in a channel, do
 
-    $ nix-channel --update
+```console
+$ nix-channel --update
+```
 
 This downloads and unpacks the Nix expressions in every channel
 (downloaded from `url/nixexprs.tar.bz2`). It also makes the union of
@@ -36,7 +42,9 @@ each channel’s Nix expressions available by default to `nix-env`
 operations (via the symlink `~/.nix-defexpr/channels`). Consequently,
 you can then say
 
-    $ nix-env -u
+```console
+$ nix-env -u
+```
 
 to upgrade all packages in your profile to the latest versions available
 in the subscribed channels.
diff --git a/doc/manual/src/package-management/garbage-collection.md b/doc/manual/src/package-management/garbage-collection.md
index 4c8799dfe..fecb30fd6 100644
--- a/doc/manual/src/package-management/garbage-collection.md
+++ b/doc/manual/src/package-management/garbage-collection.md
@@ -18,23 +18,31 @@ be done if you are certain that you will not need to roll back.
 
 To delete all old (non-current) generations of your current profile:
 
-    $ nix-env --delete-generations old
+```console
+$ nix-env --delete-generations old
+```
 
 Instead of `old` you can also specify a list of generations, e.g.,
 
-    $ nix-env --delete-generations 10 11 14
+```console
+$ nix-env --delete-generations 10 11 14
+```
 
 To delete all generations older than a specified number of days (except
 the current generation), use the `d` suffix. For example,
 
-    $ nix-env --delete-generations 14d
+```console
+$ nix-env --delete-generations 14d
+```
 
 deletes all generations older than two weeks.
 
 After removing appropriate old generations you can run the garbage
 collector as follows:
 
-    $ nix-store --gc
+```console
+$ nix-store --gc
+```
 
 The behaviour of the gargage collector is affected by the
 `keep-derivations` (default: true) and `keep-outputs` (default: false)
@@ -47,7 +55,9 @@ sense to keep outputs to ensure that rebuild times are quick.) If you
 are feeling uncertain, you can also first view what files would be
 deleted:
 
-    $ nix-store --gc --print-dead
+```console
+$ nix-store --gc --print-dead
+```
 
 Likewise, the option `--print-live` will show the paths that *won’t* be
 deleted.
@@ -56,6 +66,8 @@ There is also a convenient little utility `nix-collect-garbage`, which
 when invoked with the `-d` (`--delete-old`) switch deletes all old
 generations of all profiles in `/nix/var/nix/profiles`. So
 
-    $ nix-collect-garbage -d
+```console
+$ nix-collect-garbage -d
+```
 
 is a quick and easy way to clean up your system.
diff --git a/doc/manual/src/package-management/garbage-collector-roots.md b/doc/manual/src/package-management/garbage-collector-roots.md
index 6f4d48e80..30c5b7f8d 100644
--- a/doc/manual/src/package-management/garbage-collector-roots.md
+++ b/doc/manual/src/package-management/garbage-collector-roots.md
@@ -5,7 +5,9 @@ are symlinks in the directory `prefix/nix/var/nix/gcroots`. For
 instance, the following command makes the path
 `/nix/store/d718ef...-foo` a root of the collector:
 
-    $ ln -s /nix/store/d718ef...-foo /nix/var/nix/gcroots/bar
+```console
+$ ln -s /nix/store/d718ef...-foo /nix/var/nix/gcroots/bar
+```
 
 That is, after this command, the garbage collector will not remove
 `/nix/store/d718ef...-foo` or any of its dependencies.
diff --git a/doc/manual/src/package-management/profiles.md b/doc/manual/src/package-management/profiles.md
index f3786072d..fbbfb7320 100644
--- a/doc/manual/src/package-management/profiles.md
+++ b/doc/manual/src/package-management/profiles.md
@@ -22,7 +22,9 @@ store looks like:
 
 Of course, you wouldn’t want to type
 
-    $ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn
+```console
+$ /nix/store/dpmvp969yhdq...-subversion-1.1.3/bin/svn
+```
 
 every time you want to run Subversion. Of course we could set up the
 `PATH` environment variable to include the `bin` directory of every
@@ -36,7 +38,9 @@ environment `/nix/store/0c1p5z4kda11...-user-env` contains a symlink to
 just Subversion 1.1.2 (arrows in the figure indicate symlinks). This
 would be what we would obtain if we had done
 
-    $ nix-env -i subversion
+```console
+$ nix-env -i subversion
+```
 
 on a set of Nix expressions that contained Subversion 1.1.2.
 
@@ -49,7 +53,9 @@ since every time you perform a `nix-env` operation, a new user
 environment is generated based on the current one. For instance,
 generation 43 was created from generation 42 when we did
 
-    $ nix-env -i subversion firefox
+```console
+$ nix-env -i subversion firefox
+```
 
 on a set of Nix expressions that contained Firefox and a new version of
 Subversion.
@@ -57,11 +63,13 @@ Subversion.
 Generations are grouped together into *profiles* so that different users
 don’t interfere with each other if they don’t want to. For example:
 
-    $ ls -l /nix/var/nix/profiles/
-    ...
-    lrwxrwxrwx  1 eelco ... default-42-link -> /nix/store/0c1p5z4kda11...-user-env
-    lrwxrwxrwx  1 eelco ... default-43-link -> /nix/store/3aw2pdyx2jfc...-user-env
-    lrwxrwxrwx  1 eelco ... default -> default-43-link
+```console
+$ ls -l /nix/var/nix/profiles/
+...
+lrwxrwxrwx  1 eelco ... default-42-link -> /nix/store/0c1p5z4kda11...-user-env
+lrwxrwxrwx  1 eelco ... default-43-link -> /nix/store/3aw2pdyx2jfc...-user-env
+lrwxrwxrwx  1 eelco ... default -> default-43-link
+```
 
 This shows a profile called `default`. The file `default` itself is
 actually a symlink that points to the current generation. When we do a
@@ -75,18 +83,24 @@ store.)
 
 If you find that you want to undo a `nix-env` operation, you can just do
 
-    $ nix-env --rollback
+```console
+$ nix-env --rollback
+```
 
 which will just make the current generation link point at the previous
 link. E.g., `default` would be made to point at `default-42-link`. You
 can also switch to a specific generation:
 
-    $ nix-env --switch-generation 43
+```console
+$ nix-env --switch-generation 43
+```
 
 which in this example would roll forward to generation 43 again. You can
 also see all available generations:
 
-    $ nix-env --list-generations
+```console
+$ nix-env --list-generations
+```
 
 You generally wouldn’t have `/nix/var/nix/profiles/some-profile/bin` in
 your `PATH`. Rather, there is a symlink `~/.nix-profile` that points to
@@ -96,9 +110,11 @@ initialisation script `/nix/etc/profile.d/nix.sh` does). This makes it
 easier to switch to a different profile. You can do that using the
 command `nix-env --switch-profile`:
 
-    $ nix-env --switch-profile /nix/var/nix/profiles/my-profile
-    
-    $ nix-env --switch-profile /nix/var/nix/profiles/default
+```console
+$ nix-env --switch-profile /nix/var/nix/profiles/my-profile
+
+$ nix-env --switch-profile /nix/var/nix/profiles/default
+```
 
 These commands switch to the `my-profile` and default profile,
 respectively. If the profile doesn’t exist, it will be created
@@ -110,6 +126,8 @@ All `nix-env` operations work on the profile pointed to by
 `~/.nix-profile`, but you can override this using the `--profile` option
 (abbreviation `-p`):
 
-    $ nix-env -p /nix/var/nix/profiles/other-profile -i subversion
+```console
+$ nix-env -p /nix/var/nix/profiles/other-profile -i subversion
+```
 
 This will *not* change the `~/.nix-profile` symlink.
diff --git a/doc/manual/src/package-management/s3-substituter.md b/doc/manual/src/package-management/s3-substituter.md
index 2824c1a9b..a4f4d561f 100644
--- a/doc/manual/src/package-management/s3-substituter.md
+++ b/doc/manual/src/package-management/s3-substituter.md
@@ -51,25 +51,27 @@ cache's documentation.
 
 Your bucket will need the following bucket policy:
 
-    {
-        "Id": "DirectReads",
-        "Version": "2012-10-17",
-        "Statement": [
-            {
-                "Sid": "AllowDirectReads",
-                "Action": [
-                    "s3:GetObject",
-                    "s3:GetBucketLocation"
-                ],
-                "Effect": "Allow",
-                "Resource": [
-                    "arn:aws:s3:::example-nix-cache",
-                    "arn:aws:s3:::example-nix-cache/*"
-                ],
-                "Principal": "*"
-            }
-        ]
-    }
+```json
+{
+    "Id": "DirectReads",
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Sid": "AllowDirectReads",
+            "Action": [
+                "s3:GetObject",
+                "s3:GetBucketLocation"
+            ],
+            "Effect": "Allow",
+            "Resource": [
+                "arn:aws:s3:::example-nix-cache",
+                "arn:aws:s3:::example-nix-cache/*"
+            ],
+            "Principal": "*"
+        }
+    ]
+}
+```
 
 ## Authenticated Reads to your S3 binary cache
 
@@ -101,35 +103,43 @@ for authenticating requests to Amazon S3.
 
 Your account will need the following IAM policy to upload to the cache:
 
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [
     {
-      "Version": "2012-10-17",
-      "Statement": [
-        {
-          "Sid": "UploadToCache",
-          "Effect": "Allow",
-          "Action": [
-            "s3:AbortMultipartUpload",
-            "s3:GetBucketLocation",
-            "s3:GetObject",
-            "s3:ListBucket",
-            "s3:ListBucketMultipartUploads",
-            "s3:ListMultipartUploadParts",
-            "s3:PutObject"
-          ],
-          "Resource": [
-            "arn:aws:s3:::example-nix-cache",
-            "arn:aws:s3:::example-nix-cache/*"
-          ]
-        }
+      "Sid": "UploadToCache",
+      "Effect": "Allow",
+      "Action": [
+        "s3:AbortMultipartUpload",
+        "s3:GetBucketLocation",
+        "s3:GetObject",
+        "s3:ListBucket",
+        "s3:ListBucketMultipartUploads",
+        "s3:ListMultipartUploadParts",
+        "s3:PutObject"
+      ],
+      "Resource": [
+        "arn:aws:s3:::example-nix-cache",
+        "arn:aws:s3:::example-nix-cache/*"
       ]
     }
+  ]
+}
+```
 
 ## Examples
 
 To upload with a specific credential profile for Amazon S3:
 
-    nix copy --to 's3://example-nix-cache?profile=cache-upload&region=eu-west-2' nixpkgs.hello
+```console
+$ nix copy nixpkgs.hello \
+  --to 's3://example-nix-cache?profile=cache-upload&region=eu-west-2'
+```
 
 To upload to an S3-compatible binary cache:
 
-    nix copy --to 's3://example-nix-cache?profile=cache-upload&scheme=https&endpoint=minio.example.com' nixpkgs.hello
+```console
+$ nix copy nixpkgs.hello --to \
+  's3://example-nix-cache?profile=cache-upload&scheme=https&endpoint=minio.example.com'
+```
diff --git a/doc/manual/src/package-management/ssh-substituter.md b/doc/manual/src/package-management/ssh-substituter.md
index 482844c7c..6e5e258bc 100644
--- a/doc/manual/src/package-management/ssh-substituter.md
+++ b/doc/manual/src/package-management/ssh-substituter.md
@@ -5,7 +5,9 @@ Nix store via SSH. For example, the following installs Firefox,
 automatically fetching any store paths in Firefox’s closure if they are
 available on the server `avalon`:
 
-    $ nix-env -i firefox --substituters ssh://alice@avalon
+```console
+$ nix-env -i firefox --substituters ssh://alice@avalon
+```
 
 This works similar to the binary cache substituter that Nix usually
 uses, only using SSH instead of HTTP: if a store path `P` is needed, Nix
@@ -22,11 +24,17 @@ building from source.
 You can also copy the closure of some store path, without installing it
 into your profile, e.g.
 
-    $ nix-store -r /nix/store/m85bxg…-firefox-34.0.5 --substituters ssh://alice@avalon
+```console
+$ nix-store -r /nix/store/m85bxg…-firefox-34.0.5 --substituters
+ssh://alice@avalon
+```
 
 This is essentially equivalent to doing
 
-    $ nix-copy-closure --from alice@avalon /nix/store/m85bxg…-firefox-34.0.5
+```console
+$ nix-copy-closure --from alice@avalon
+/nix/store/m85bxg…-firefox-34.0.5
+```
 
 You can use SSH’s *forced command* feature to set up a restricted user
 account for SSH substituter access, allowing read-only access to the
@@ -45,8 +53,10 @@ to `sshd_config` to restrict the user `nix-ssh`:
 On NixOS, you can accomplish the same by adding the following to your
 `configuration.nix`:
 
-    nix.sshServe.enable = true;
-    nix.sshServe.keys = [ "ssh-dss AAAAB3NzaC1k... bob@example.org" ];
+```nix
+nix.sshServe.enable = true;
+nix.sshServe.keys = [ "ssh-dss AAAAB3NzaC1k... bob@example.org" ];
+```
 
 where the latter line lists the public keys of users that are allowed to
 connect.