1 files changed, 81 insertions, 81 deletions

diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc
index c6ff1952a7..3848a401ff 100644
--- a/documentation/content/en/articles/committers-guide/_index.adoc
+++ b/documentation/content/en/articles/committers-guide/_index.adoc
@@ -112,7 +112,7 @@ cert-digest-algo SHA512
 ....
 . Generate a key:
 +
-[source,bash]
+[source,shell]
 ....
 % gpg --full-gen-key
 gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
@@ -173,7 +173,7 @@ The FreeBSD cluster requires a Kerberos password to access certain services. The
 
 To create a new Kerberos account in the FreeBSD cluster, or to reset a Kerberos password for an existing account using a random password generator:
 
-[source,bash]
+[source,shell]
 ....
 % ssh kpasswd.freebsd.org
 ....
@@ -185,7 +185,7 @@ This must be done from a machine outside of the FreeBSD.org cluster.
 
 A Kerberos password can also be set manually by logging into `freefall.FreeBSD.org` and running:
 
-[source,bash]
+[source,shell]
 ....
 % kpasswd
 ....
@@ -251,7 +251,7 @@ The FreeBSD `ports` repository switched from CVS to Subversion on July 14th, 201
 
 Subversion can be installed from the FreeBSD Ports Collection by issuing these commands:
 
-[source,bash]
+[source,shell]
 ....
 # pkg install subversion
 ....
@@ -266,21 +266,21 @@ There are a few ways to obtain a working copy of the tree from Subversion. This
 
 The first is to check out directly from the main repository. For the `src` tree, use:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout svn+ssh://repo.freebsd.org/base/head /usr/src
 ....
 
 For the `doc` tree, use:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout svn+ssh://repo.freebsd.org/doc/head /usr/doc
 ....
 
 For the `ports` tree, use:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout svn+ssh://repo.freebsd.org/ports/head /usr/ports
 ....
@@ -361,7 +361,7 @@ This section will explain how to perform common day-to-day operations with Subve
 
 SVN has built in help documentation. It can be accessed by typing:
 
-[source,bash]
+[source,shell]
 ....
 % svn help
 ....
@@ -373,7 +373,7 @@ Additional information can be found in the http://svnbook.red-bean.com/[Subversi
 
 As seen earlier, to check out the FreeBSD head branch:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout svn+ssh://repo.freebsd.org/base/head /usr/src
 ....
@@ -382,7 +382,7 @@ At some point, more than just `HEAD` will probably be useful, for instance when
 
 To do this, first check out the root of the repository:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout --depth=immediates svn+ssh://repo.freebsd.org/base
 ....
@@ -391,7 +391,7 @@ This will give `base` with all the files it contains (at the time of writing, ju
 
 Expanding the working copy is possible. Just change the depth of the various subdirectories:
 
-[source,bash]
+[source,shell]
 ....
 % svn up --set-depth=infinity base/head
 % svn up --set-depth=immediates base/release base/releng base/stable
@@ -401,14 +401,14 @@ The above command will pull down a full copy of `head`, plus empty copies of eve
 
 If at a later date merging to `7-STABLE` is required, expand the working copy:
 
-[source,bash]
+[source,shell]
 ....
 % svn up --set-depth=infinity base/stable/7
 ....
 
 Subtrees do not have to be expanded completely. For instance, expanding only `stable/7/sys` and then later expand the rest of `stable/7`:
 
-[source,bash]
+[source,shell]
 ....
 % svn up --set-depth=infinity base/stable/7/sys
 % svn up --set-depth=infinity base/stable/7
@@ -421,7 +421,7 @@ Updating the tree with `svn update` will only update what was previously asked f
 
 It is possible to anonymously check out the FreeBSD repository with Subversion. This will give access to a read-only tree that can be updated, but not committed back to the main repository. To do this, use:
 
-[source,bash]
+[source,shell]
 ....
 % svn co https://svn.FreeBSD.org/base/head /usr/src
 ....
@@ -433,7 +433,7 @@ More details on using Subversion this way can be found in link:{handbook}#svn[Us
 
 To update a working copy to either the latest revision, or a specific revision:
 
-[source,bash]
+[source,shell]
 ....
 % svn update
 % svn update -r12345
@@ -444,14 +444,14 @@ To update a working copy to either the latest revision, or a specific revision:
 
 To view the local changes that have been made to the working copy:
 
-[source,bash]
+[source,shell]
 ....
 % svn status
 ....
 
 To show local changes and files that are out-of-date do:
 
-[source,bash]
+[source,shell]
 ....
 % svn status --show-updates
 ....
@@ -463,21 +463,21 @@ SVN does not need to be told in advance about file editing.
 
 To commit all changes in the current directory and all subdirectories:
 
-[source,bash]
+[source,shell]
 ....
 % svn commit
 ....
 
 To commit all changes in, for example, [.filename]#lib/libfetch/# and [.filename]#usr/bin/fetch/# in a single operation:
 
-[source,bash]
+[source,shell]
 ....
 % svn commit lib/libfetch usr/bin/fetch
 ....
 
 There is also a commit wrapper for the ports tree to handle the properties and sanity checking the changes:
 
-[source,bash]
+[source,shell]
 ....
 % /usr/ports/Tools/scripts/psvn commit
 ....
@@ -492,7 +492,7 @@ Before adding files, get a copy of https://people.FreeBSD.org/~peter/auto-props.
 
 Files are added to a SVN repository with `svn add`. To add a file named __foo__, edit it, then:
 
-[source,bash]
+[source,shell]
 ....
 % svn add foo
 ....
@@ -504,7 +504,7 @@ Most new source files should include a `$FreeBSD$` string near the start of the
 
 Files can be removed with `svn remove`:
 
-[source,bash]
+[source,shell]
 ....
 % svn remove foo
 ....
@@ -513,7 +513,7 @@ Subversion does not require deleting the file before using `svn rm`, and indeed
 
 It is possible to add directories with `svn add`:
 
-[source,bash]
+[source,shell]
 ....
 % mkdir bar
 % svn add bar
@@ -521,14 +521,14 @@ It is possible to add directories with `svn add`:
 
 Although `svn mkdir` makes this easier by combining the creation of the directory and the adding of it:
 
-[source,bash]
+[source,shell]
 ....
 % svn mkdir bar
 ....
 
 Like files, directories are removed with `svn rm`. There is no separate command specifically for removing directories.
 
-[source,bash]
+[source,shell]
 ....
 % svn rm bar
 ....
@@ -538,7 +538,7 @@ Like files, directories are removed with `svn rm`. There is no separate command
 
 This command creates a copy of [.filename]#foo.c# named [.filename]#bar.c#, with the new file also under version control and with the full history of [.filename]#foo.c#:
 
-[source,bash]
+[source,shell]
 ....
 % svn copy foo.c bar.c
 ....
@@ -547,7 +547,7 @@ This is usually preferred to copying the file with `cp` and adding it to the rep
 
 To move and rename a file:
 
-[source,bash]
+[source,shell]
 ....
 % svn move foo.c bar.c
 ....
@@ -566,14 +566,14 @@ To move and rename a file:
 
 `svn diff` can show the changes between two revisions of the same file:
 
-[source,bash]
+[source,shell]
 ....
 % svn diff -r179453:179454 ROADMAP.txt
 ....
 
 It can also show all changes for a specific changeset. This command shows what changes were made to the current directory and all subdirectories in changeset 179454:
 
-[source,bash]
+[source,shell]
 ....
 % svn diff -c179454 .
 ....
@@ -588,14 +588,14 @@ Local changes (including additions and deletions) can be reverted using `svn rev
 
 If an `svn update` resulted in a merge conflict, Subversion will remember which files have conflicts and refuse to commit any changes to those files until explicitly told that the conflicts have been resolved. The simple, not yet deprecated procedure is:
 
-[source,bash]
+[source,shell]
 ....
 % svn resolved foo
 ....
 
 However, the preferred procedure is:
 
-[source,bash]
+[source,shell]
 ....
 % svn resolve --accept=working foo
 ....
@@ -625,7 +625,7 @@ The `--depth` option applies to many other commands, including `svn commit`, `sv
 
 Since `--depth` is sticky, there is a `--set-depth` option for `svn update` that will change the selected depth. Thus, given the working copy produced by the previous example:
 
-[source,bash]
+[source,shell]
 ....
 % cd ~/freebsd
 % svn update --set-depth=immediates .
@@ -633,7 +633,7 @@ Since `--depth` is sticky, there is a `--set-depth` option for `svn update` that
 
 The above command will populate the working copy in _~/freebsd_ with [.filename]#ROADMAP.txt# and empty subdirectories, and nothing will happen when `svn update` is executed on the subdirectories. However, this command will set the depth for _head_ (in this case) to infinity, and fully populate it:
 
-[source,bash]
+[source,shell]
 ....
 % svn update --set-depth=infinity head
 ....
@@ -651,14 +651,14 @@ Certain operations can be performed directly on the repository without touching
 
 Branching is very fast. This command would be used to branch `RELENG_8`:
 
-[source,bash]
+[source,shell]
 ....
 % svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/stable/8
 ....
 
 This is equivalent to these commands which take minutes and hours as opposed to seconds, depending on your network connection:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout --depth=immediates svn+ssh://repo.freebsd.org/base
 % cd base
@@ -694,7 +694,7 @@ If you consider the case where a revision changes several separate parts of the
 
 Merging to `stable/` branches should originate from `head/`. For example:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c r123456 ^/head/ stable/11
 % svn commit stable/11
@@ -702,7 +702,7 @@ Merging to `stable/` branches should originate from `head/`. For example:
 
 Merges to `releng/` branches should always originate from the corresponding `stable/` branch. For example:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c r123456 ^/stable/11  releng/11.0
 % svn commit releng/11.0
@@ -715,7 +715,7 @@ Committers are only permitted to commit to the `releng/` branches during a relea
 
 All merges are merged to and committed from the root of the branch. All merges look like:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c r123456 ^/head/ checkout
 % svn commit checkout
@@ -723,7 +723,7 @@ All merges are merged to and committed from the root of the branch. All merges l
 
 Note that _checkout_ must be a complete checkout of the branch to which the merge occurs.
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c r123456 ^/stable/10 releng/10.0
 ....
@@ -732,7 +732,7 @@ Note that _checkout_ must be a complete checkout of the branch to which the merg
 
 Due to the mergeinfo propagation issues described earlier, it is very important to never merge changes into a sparse working copy. Always use a full checkout of the branch being merged into. For instance, when merging from HEAD to 7, use a full checkout of stable/7:
 
-[source,bash]
+[source,shell]
 ....
 % cd stable/7
 % svn up --set-depth=infinity
@@ -744,7 +744,7 @@ The target directory must also be up-to-date and must not contain any uncommitte
 
 Identifying revisions to be merged is a must. If the target already has complete mergeinfo, ask SVN for a list:
 
-[source,bash]
+[source,shell]
 ....
 % cd stable/6/contrib/openpam
 % svn mergeinfo --show-revs=eligible $FSVN/head/contrib/openpam
@@ -767,7 +767,7 @@ For example, To merge:
 
 Assuming that revisions $P and $Q have already been merged, and that the current directory is an up-to-date working copy of stable/$B, the existing mergeinfo looks like this:
 
-[source,bash]
+[source,shell]
 ....
 % svn propget svn:mergeinfo -R $target
 $target - /head/$source:$P,$Q
@@ -775,7 +775,7 @@ $target - /head/$source:$P,$Q
 
 Merging is done like so:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c$R $FSVN/head/$source $target
 ....
@@ -784,7 +784,7 @@ Checking the results of this is possible with `svn diff`.
 
 The svn:mergeinfo now looks like:
 
-[source,bash]
+[source,shell]
 ....
 % svn propget svn:mergeinfo -R $target
 $target - head/$source:$P,$Q,$R
@@ -798,14 +798,14 @@ As a practical example, consider this scenario. The changes to [.filename]#netma
 
 The first step is to inspect the existing mergeinfo.
 
-[source,bash]
+[source,shell]
 ....
 % svn propget svn:mergeinfo -R stable/9/shared/man/man4
 ....
 
 Take a quick note of how it looks before moving on to the next step; doing the actual merge:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c r238987 svn+ssh://repo.freebsd.org/base/head/shared/man/man4 stable/9/shared/man/man4
 --- Merging r238987 into 'stable/9/shared/man/man4':
@@ -817,7 +817,7 @@ U    stable/9/shared/man/man4/netmap.4
 
 Check that the revision number of the merged revision has been added. Once this is verified, the only thing left is the actual commit.
 
-[source,bash]
+[source,shell]
 ....
 % svn commit stable/9/shared/man/man4
 ....
@@ -868,7 +868,7 @@ During the conversion from `CVS` to Subversion, vendor branches were imported wi
 
 To flatten the `pf` tree:
 
-[source,bash]
+[source,shell]
 ....
 % cd vendor/pf/dist/contrib/pf
 % svn mv $(svn list) ../..
@@ -886,7 +886,7 @@ Tags may be flattened as well (3, 4, 3.5 etc.); the procedure is exactly the sam
 
 The `dist` tree can be cleaned up as necessary. Disabling keyword expansion is recommended, as it makes no sense on unmodified vendor code and in some cases it can even be harmful. OpenSSH, for example, includes two files that originated with FreeBSD and still contain the original version tags. To do this:
 
-[source,bash]
+[source,shell]
 ....
 % svn propdel svn:keywords -R .
 % svn commit
@@ -896,7 +896,7 @@ The `dist` tree can be cleaned up as necessary. Disabling keyword expansion is r
 
 If importing for the first time after the switch to Subversion, bootstrap `svn:mergeinfo` on the target directory in the main tree to the revision that corresponds to the last related change to the vendor tree, prior to importing new sources:
 
-[source,bash]
+[source,shell]
 ....
 % cd head/contrib/pf
 % svn merge --record-only svn+ssh://repo.freebsd.org/base/vendor/pf/dist@180876 .
@@ -913,7 +913,7 @@ Subversion is able to store a full distribution in the vendor tree. So, import e
 
 A `svn add` is required to add any files that were added since the last vendor import, and `svn rm` is required to remove any that were removed since. Preparing sorted lists of the contents of the vendor tree and of the sources that are about to be imported is recommended, to facilitate the process.
 
-[source,bash]
+[source,shell]
 ....
 % cd vendor/pf/dist
 % svn list -R | grep -v '/$' | sort >../old
@@ -927,7 +927,7 @@ With these two files, `comm -23 ../old ../new` will list removed files (files on
 
 Now, the sources must be copied into [.filename]#dist# and the `svn add` and `svn rm` commands are used as needed:
 
-[source,bash]
+[source,shell]
 ....
 % cd vendor/pf/pf-4.3
 % tar cf - . | tar xf - -C ../dist
@@ -946,7 +946,7 @@ Committing is now possible. However, it is good practice to make sure that every
 
 Once committed, vendor releases are tagged for future reference. The best and quickest way to do this is directly in the repository:
 
-[source,bash]
+[source,shell]
 ....
 % svn cp svn+ssh://repo.freebsd.org/base/vendor/pf/dist svn+ssh://repo.freebsd.org/base/vendor/pf/4.3
 ....
@@ -955,7 +955,7 @@ Once that is complete, `svn up` the working copy of [.filename]#vendor/pf# to ge
 
 If creating the tag in the working copy of the tree, `svn:mergeinfo` results must be removed:
 
-[source,bash]
+[source,shell]
 ....
 % cd	vendor/pf
 % svn cp dist 4.3
@@ -964,7 +964,7 @@ If creating the tag in the working copy of the tree, `svn:mergeinfo` results mus
 
 ===== Merging to Head
 
-[source,bash]
+[source,shell]
 ....
 % cd head/contrib/pf
 % svn up
@@ -978,7 +978,7 @@ The `--accept=postpone` tells Subversion not to complain about merge conflicts a
 
 The `cvs2svn` changeover occurred on June 3, 2008. When performing vendor merges for packages which were already present and converted by the `cvs2svn` process, the command used to merge [.filename]#/vendor/package_name/dist# to [.filename]#/head/package_location# (for example, [.filename]#head/contrib/sendmail#) must use `-c _REV_` to indicate the revision to merge from the [.filename]#/vendor# tree. For example:
 
-[source,bash]
+[source,shell]
 ....
 % svn checkout svn+ssh://repo.freebsd.org/base/head/contrib/sendmail
 % cd sendmail
@@ -997,7 +997,7 @@ It is necessary to resolve any merge conflicts.
 
 Make sure that any files that were added or removed in the vendor tree have been properly added or removed in the main tree. To check diffs against the vendor branch:
 
-[source,bash]
+[source,shell]
 ....
 % svn diff --no-diff-deleted --old=svn+ssh://repo.freebsd.org/base/vendor/pf/dist --new=.
 ....
@@ -1020,7 +1020,7 @@ This section is an example of importing and tagging byacc into [.filename]#head#
 
 First, prepare the directory in [.filename]#vendor#:
 
-[source,bash]
+[source,shell]
 ....
 % svn co --depth immediates $FSVN/vendor
 % cd vendor
@@ -1030,7 +1030,7 @@ First, prepare the directory in [.filename]#vendor#:
 
 Now, import the sources into the [.filename]#dist# directory. Once the files are in place, `svn add` the new ones, then `svn commit` and tag the imported version. To save time and bandwidth, direct remote committing and tagging is possible:
 
-[source,bash]
+[source,shell]
 ....
 % svn cp -m "Tag byacc 20120115" $FSVN/vendor/byacc/dist $FSVN/vendor/byacc/20120115
 ....
@@ -1039,7 +1039,7 @@ Now, import the sources into the [.filename]#dist# directory. Once the files are
 
 Due to this being a new file, copy it for the merge:
 
-[source,bash]
+[source,shell]
 ....
 % svn cp -m "Import byacc to contrib" $FSVN/vendor/byacc/dist $FSVN/head/contrib/byacc
 ....
@@ -1051,7 +1051,7 @@ Working normally on newly imported sources is still possible.
 
 Reverting a commit to a previous version is fairly easy:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -r179454:179453 ROADMAP.txt
 % svn commit
@@ -1059,7 +1059,7 @@ Reverting a commit to a previous version is fairly easy:
 
 Change number syntax, with negative meaning a reverse change, can also be used:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -c -179454 ROADMAP.txt
 % svn commit
@@ -1067,7 +1067,7 @@ Change number syntax, with negative meaning a reverse change, can also be used:
 
 This can also be done directly in the repository:
 
-[source,bash]
+[source,shell]
 ....
 % svn merge -r179454:179453 svn+ssh://repo.freebsd.org/base/ROADMAP.txt
 ....
@@ -1079,7 +1079,7 @@ It is important to ensure that the mergeinfo is correct when reverting a file to
 
 Reverting the deletion of a file is slightly different. Copying the version of the file that predates the deletion is required. For example, to restore a file that was deleted in revision N, restore version N-1:
 
-[source,bash]
+[source,shell]
 ....
 % svn copy svn+ssh://repo.freebsd.org/base/ROADMAP.txt@179454
 % svn commit
@@ -1087,7 +1087,7 @@ Reverting the deletion of a file is slightly different. Copying the version of t
 
 or, equally:
 
-[source,bash]
+[source,shell]
 ....
 % svn copy svn+ssh://repo.freebsd.org/base/ROADMAP.txt@179454 svn+ssh://repo.freebsd.org/base
 ....
@@ -1124,7 +1124,7 @@ One way to limit the time required is to grab a https://download.freebsd.org/ftp
 
 Extract the file and update it:
 
-[source,bash]
+[source,shell]
 ....
 % tar xf svnmirror-base-r261170.tar.xz
 % svnsync sync file:///home/svnmirror/base
@@ -1134,7 +1134,7 @@ Now, set that up to run from man:cron[8], do checkouts locally, set up a svnserv
 
 The seed mirror is set to fetch from `svn://svn.freebsd.org/base`. The configuration for the mirror is stored in `revprop 0` on the local mirror. To see the configuration, try:
 
-[source,bash]
+[source,shell]
 ....
 % svn proplist -v --revprop -r 0 file:///home/svnmirror/base
 ....
@@ -1146,7 +1146,7 @@ Use `svn propset` to change things.
 
 Files that have high-ASCII bits are considered binary files in SVN, so the pre-commit checks fail and indicate that the `mime-type` property should be set to `application/octet-stream`. However, the use of this is discouraged, so please do not set it. The best way is always avoiding high-ASCII data, so that it can be read everywhere with any text editor but if it is not avoidable, instead of changing the mime-type, set the `fbsd:notbinary` property with `propset`:
 
-[source,bash]
+[source,shell]
 ....
 % svn propset fbsd:notbinary yes foo.data
 ....
@@ -1160,14 +1160,14 @@ As per https://people.FreeBSD.org/\~peter/svn_notes.txt[https://people.FreeBSD.o
 
 To create a project branch:
 
-[source,bash]
+[source,shell]
 ....
 % svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/projects/spif
 ....
 
 To merge changes from HEAD back into the project branch:
 
-[source,bash]
+[source,shell]
 ....
 % cd copy_of_spif
 % svn merge svn+ssh://repo.freebsd.org/base/head
@@ -1182,7 +1182,7 @@ In commit logs etc., "rev 179872" is spelled "r179872" as per convention.
 
 Speeding up svn is possible by adding these entries to [.filename]#~/.ssh/config#:
 
-[source,bash]
+[source,shell]
 ....
 Host *
 ControlPath ~/.ssh/sockets/master-l-r@h:p
@@ -1192,14 +1192,14 @@ ControlPersist yes
 
 and then typing
 
-[source,bash]
+[source,shell]
 ....
  mkdir ~/.ssh/sockets
 ....
 
 Checking out a working copy with a stock Subversion client without FreeBSD-specific patches (`OPTIONS_SET=FREEBSD_TEMPLATE`) will mean that `$FreeBSD$` tags will not be expanded. Once the correct version has been installed, trick Subversion into expanding them like so:
 
-[source,bash]
+[source,shell]
 ....
 % svn propdel -R svn:keywords .
 % svn revert -R .
@@ -1630,14 +1630,14 @@ There are several cases where approval is customary:
 
 While under mentorship, get mentor approval before the commit. Enter the mentor's username in this field, and note that they are a mentor:
 
-[source,bash]
+[source,shell]
 ....
 Approved by: username-of-mentor (mentor)
 ....
 
 If a team approved these commits then include the team name followed by the username of the approver in parentheses. For example:
 
-[source,bash]
+[source,shell]
 ....
 Approved by: re (username)
 ....
@@ -2226,7 +2226,7 @@ The easiest way to add a new port is the `addport` script located in the [.filen
 
 Check the port, preferably to make sure it compiles and packages correctly. This is the recommended sequence:
 
-[source,bash]
+[source,shell]
 ....
 # make install
 # make package
@@ -2292,7 +2292,7 @@ Do not use `svn add` to add the port. Follow these steps. If they are unclear, o
 ====
 . Figure out when the port was removed. Use this link:https://people.freebsd.org/~crees/removed_ports/index.xml[list], or look for the port on link:http://www.freshports.org/[freshports], and then copy the last living revision of the port:
 +
-[source,bash]
+[source,shell]
 ....
 % cd /usr/ports/category
 % svn cp 'svn+ssh://repo.freebsd.org/ports/head/category/portname/@XXXXXX' portname
@@ -2302,7 +2302,7 @@ Pick the revision that is just before the removal. For example, if the revision
 +
 It is also possible to specify a date. In that case, pick a date that is before the removal but after the last commit to the port.
 +
-[source,bash]
+[source,shell]
 ....
 % cd /usr/ports/category
 % svn cp 'svn+ssh://repo.freebsd.org/ports/head/category/portname/@{YYYY-MM-DD}' portname
@@ -2443,7 +2443,7 @@ Commits that are not covered by these blanket approvals always require explicit
 
 A script is provided to automate merging a specific commit: [.filename]#ports/Tools/scripts/mfh#. It is used as follows:
 
-[source,bash]
+[source,shell]
 ....
 % /usr/ports/Tools/scripts/mfh 380362
  U   2015Q1
@@ -2519,7 +2519,7 @@ Host *.freebsd.org
 ====
 The script is also able to merge more than one revision at a time. If there have been other updates to the port since the branch was created that have not been merged because they were not security related. Add the different revisions in the order they were committed on the `mfh` line. The new commit log message will contain the combined log messages from all the original commits. These messages must be edited to show what is actually being done with the new commit.
 
-[source,bash]
+[source,shell]
 ....
 % /usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728
 ....
@@ -2529,7 +2529,7 @@ The script is also able to merge more than one revision at a time. If there have
 ====
 The mfh script can also take an optional first argument, the branch where the merge is being done. Only the latest quarterly branch is supported, so specifying the branch is discouraged. To be safe, the script will give a warning if the quarterly branch is not the latest:
 
-[source,bash]
+[source,shell]
 ....
 % /usr/ports/Tools/scripts/mfh 2016Q1 r407208 r407713
 /!\ The latest branch is 2016Q2, do you really want to commit to 2016Q1? [y/n]