1 files changed, 50 insertions, 50 deletions

diff --git a/documentation/content/en/books/developers-handbook/tools/chapter.adoc b/documentation/content/en/books/developers-handbook/tools/_index.adoc
index a00ea30e31..feeaee40b8 100644
--- a/documentation/content/en/books/developers-handbook/tools/chapter.adoc
+++ b/documentation/content/en/books/developers-handbook/tools/_index.adoc
@@ -141,14 +141,14 @@ The word _compiling_ is often used to refer to just steps 1 to 4-the others are
 
 Fortunately, almost all this detail is hidden from you, as `cc` is a front end that manages calling all these programs with the right arguments for you; simply typing
 
-[source,shell]
+[source,bash]
 ....
 % cc foobar.c
 ....
 
 will cause [.filename]#foobar.c# to be compiled by all the steps above. If you have more than one file to compile, just do something like
 
-[source,shell]
+[source,bash]
 ....
 % cc foo.c bar.c
 ....
@@ -160,7 +160,7 @@ There are lots and lots of options for `cc`, which are all in the manual page. H
 `-o _filename_`::
 The output name of the file. If you do not use this option, `cc` will produce an executable called [.filename]#a.out#.footnote:[The reasons for this are buried in the mists of history.]
 +
-[source,shell]
+[source,bash]
 ....
 % cc foobar.c               executable is a.out
 % cc -o foobar foobar.c     executable is foobar
@@ -169,7 +169,7 @@ The output name of the file. If you do not use this option, `cc` will produce an
 `-c`::
 Just compile the file, do not link it. Useful for toy programs where you just want to check the syntax, or if you are using a [.filename]#Makefile#.
 +
-[source,shell]
+[source,bash]
 ....
 % cc -c foobar.c
 ....
@@ -180,7 +180,7 @@ This will produce an _object file_ (not an executable) called [.filename]#foobar
 Create a debug version of the executable. This makes the compiler put information into the executable about which line of which source file corresponds to which function call. A debugger can use this information to show the source code as you step through the program, which is _very_ useful; the disadvantage is that all this extra information makes the program much bigger. Normally, you compile with `-g` while you are developing a program and then compile a "release version" without `-g` when you are satisfied it works properly.
 +
 
-[source,shell]
+[source,bash]
 ....
 % cc -g foobar.c
 ....
@@ -190,7 +190,7 @@ This will produce a debug version of the program. footnote:[Note, we did not use
 `-O`::
 Create an optimized version of the executable. The compiler performs various clever tricks to try to produce an executable that runs faster than normal. You can add a number after the `-O` to specify a higher level of optimization, but this often exposes bugs in the compiler's optimizer.
 +
-[source,shell]
+[source,bash]
 ....
 % cc -O -o foobar foobar.c
 ....
@@ -212,7 +212,7 @@ Without these flags, `cc` will allow you to use some of its non-standard extensi
 
 Generally, you should try to make your code as portable as possible, as otherwise you may have to completely rewrite the program later to get it to work somewhere else-and who knows what you may be using in a few years time?
 
-[source,shell]
+[source,bash]
 ....
 % cc -Wall -ansi -pedantic -o foobar foobar.c
 ....
@@ -226,7 +226,7 @@ The most common example of this is when compiling a program that uses some of th
 +
 The rule is that if the library is called [.filename]#libsomething.a#, you give `cc` the argument `-l__something__`. For example, the math library is [.filename]#libm.a#, so you give `cc` the argument `-lm`. A common "gotcha" with the math library is that it has to be the last library on the command line.
 +
-[source,shell]
+[source,bash]
 ....
 % cc -o foobar foobar.c -lm
 ....
@@ -235,7 +235,7 @@ This will link the math library functions into [.filename]#foobar#.
 +
 If you are compiling C++ code, use {c-plus-plus-command}. {c-plus-plus-command} can also be invoked as {clang-plus-plus-command} on FreeBSD.
 +
-[source,shell]
+[source,bash]
 ....
 % c++ -o foobar foobar.cc
 ....
@@ -246,14 +246,14 @@ This will both produce an executable [.filename]#foobar# from the C++ source fil
 
 ==== I am trying to write a program which uses the sin() function and I get an error like this. What does it mean?
 
-[source,shell]
+[source,bash]
 ....
 /var/tmp/cc0143941.o: Undefined symbol `_sin' referenced from text segment
 ....
 
 When using mathematical functions like `sin()`, you have to tell `cc` to link in the math library, like so:
 
-[source,shell]
+[source,bash]
 ....
 % cc -o foobar foobar.c -lm
 ....
@@ -275,14 +275,14 @@ int main() {
 
 and I compiled it as:
 
-[source,shell]
+[source,bash]
 ....
 % cc temp.c -lm
 ....
 
 like you said I should, but I get this when I run it:
 
-[source,shell]
+[source,bash]
 ....
 % ./a.out
 2.1 ^ 6 = 1023.000000
@@ -307,7 +307,7 @@ int main() {
 
 After recompiling it as you did before, run it:
 
-[source,shell]
+[source,bash]
 ....
 % ./a.out
 2.1 ^ 6 = 85.766121
@@ -319,7 +319,7 @@ If you are using any of the mathematical functions, _always_ include [.filename]
 
 Remember, `cc` will call the executable [.filename]#a.out# unless you tell it differently. Use the `-o _filename_` option:
 
-[source,shell]
+[source,bash]
 ....
 % cc -o foobar foobar.c
 ....
@@ -332,7 +332,7 @@ Unlike MS-DOS(R), UNIX(R) does not look in the current directory when it is tryi
 
 Most UNIX(R) systems have a program called `test` in [.filename]#/usr/bin# and the shell is picking that one up before it gets to checking the current directory. Either type:
 
-[source,shell]
+[source,bash]
 ....
 % ./test
 ....
@@ -414,14 +414,14 @@ No, fortunately not (unless of course you really do have a hardware problem...).
 
 Yes, just go to another console or xterm, do
 
-[source,shell]
+[source,bash]
 ....
 % ps
 ....
 
 to find out the process ID of your program, and do
 
-[source,shell]
+[source,bash]
 ....
 % kill -ABRT pid
 ....
@@ -441,7 +441,7 @@ If you want to create a core dump from outside your program, but do not want the
 
 When you are working on a simple program with only one or two source files, typing in
 
-[source,shell]
+[source,bash]
 ....
 % cc file1.c file2.c
 ....
@@ -450,7 +450,7 @@ is not too bad, but it quickly becomes very tedious when there are several files
 
 One way to get around this is to use object files and only recompile the source file if the source code has changed. So we could have something like:
 
-[source,shell]
+[source,bash]
 ....
 % cc file1.o file2.o … file37.c …
 ....
@@ -498,7 +498,7 @@ install:
 
 We can tell make which target we want to make by typing:
 
-[source,shell]
+[source,bash]
 ....
 % make target
 ....
@@ -578,15 +578,15 @@ Now I think you will agree that is rather impressive for a four line script!
 
 The secret lies in the last line, which tells `make` to look in the system makefile called [.filename]#bsd.port.mk#. It is easy to overlook this line, but this is where all the clever stuff comes from-someone has written a makefile that tells `make` to do all the things above (plus a couple of other things I did not mention, including handling any errors that may occur) and anyone can get access to that just by putting a single line in their own make file!
 
-If you want to have a look at these system makefiles, they are in [.filename]#/usr/share/mk#, but it is probably best to wait until you have had a bit of practice with makefiles, as they are very complicated (and if you do look at them, make sure you have a flask of strong coffee handy!)
+If you want to have a look at these system makefiles, they are in [.filename]#/usr/shared/mk#, but it is probably best to wait until you have had a bit of practice with makefiles, as they are very complicated (and if you do look at them, make sure you have a flask of strong coffee handy!)
 
 === More Advanced Uses of `make`
 
 `Make` is a very powerful tool, and can do much more than the simple example above shows. Unfortunately, there are several different versions of `make`, and they all differ considerably. The best way to learn what they can do is probably to read the documentation-hopefully this introduction will have given you a base from which you can do this.
 
-The version of make that comes with FreeBSD is the Berkeley make; there is a tutorial for it in [.filename]#/usr/share/doc/psd/12.make#. To view it, do
+The version of make that comes with FreeBSD is the Berkeley make; there is a tutorial for it in [.filename]#/usr/shared/doc/psd/12.make#. To view it, do
 
-[source,shell]
+[source,bash]
 ....
 % zmore paper.ascii.gz
 ....
@@ -611,7 +611,7 @@ to the file. Once you have done this, you can type `info` and then select [.guim
 
 Using a debugger allows running the program under more controlled circumstances. Typically, it is possible to step through the program a line at a time, inspect the value of variables, change them, tell the debugger to run up to a certain point and then stop, and so on. It is also possible to attach to a program that is already running, or load a core file to investigate why the program crashed. It is even possible to debug the kernel, though that is a little trickier than the user applications we will be discussing in this section.
 
-This section is intended to be a quick introduction to using debuggers and does not cover specialized topics such as debugging the kernel. For more information about that, refer to <<kerneldebug,Kernel Debugging>>.
+This section is intended to be a quick introduction to using debuggers and does not cover specialized topics such as debugging the kernel. For more information about that, refer to crossref:kerneldebug[kerneldebug,Kernel Debugging].
 
 The standard debugger supplied with FreeBSD {rel121-current} is called `lldb` (LLVM debugger). As it is part of the standard installation for that release, there is no need to do anything special to use it. It has good command help, accessible via the `help` command, as well as https://lldb.llvm.org/[a web tutorial and documentation].
 
@@ -630,7 +630,7 @@ Which one to use is largely a matter of taste. If familiar with one only, use th
 
 Start up lldb by typing
 
-[source,shell]
+[source,bash]
 ....
 % lldb -- progname
 ....
@@ -639,7 +639,7 @@ Start up lldb by typing
 
 Compile the program with `-g` to get the most out of using `lldb`. It will work without, but will only display the name of the function currently running, instead of the source code. If it displays a line like:
 
-[source,shell]
+[source,bash]
 ....
 Breakpoint 1: where = temp`main, address = …
 ....
@@ -682,7 +682,7 @@ This program sets i to be `5` and passes it to a function `bazz()` which prints
 
 Compiling and running the program displays
 
-[source,shell]
+[source,bash]
 ....
 % cc -g -o temp temp.c
 % ./temp
@@ -692,7 +692,7 @@ anint = -5360
 
 That is not what was expected! Time to see what is going on!
 
-[source,shell]
+[source,bash]
 ....
 % lldb -- temp
 (lldb) target create "temp"
@@ -740,7 +740,7 @@ Process 9992 stopped
 
 Hang on a minute! How did anint get to be `-5360`? Was it not set to `5` in `main()`? Let us move up to `main()` and have a look.
 
-[source,shell]
+[source,bash]
 ....
 (lldb) up		Move up call stack
 frame #1: 0x000000000020130b temp`main at temp.c:9:2		lldb displays stack frame
@@ -783,7 +783,7 @@ To examine a core file, specify the name of the core file in addition to the pro
 
 The debugger will display something like this:
 
-[source,shell,subs="verbatim,quotes"]
+[source,bash,subs="verbatim,quotes"]
 ....
 % lldb -c [.filename]#progname.core# -- [.filename]#progname#
 (lldb) target create "[.filename]#progname#" --core "[.filename]#progname#.core"
@@ -793,7 +793,7 @@ Core file '/home/pauamma/tmp/[.filename]#progname.core#' (x86_64) was loaded.
 
 In this case, the program was called [.filename]#progname#, so the core file is called [.filename]#progname.core#. The debugger does not display why the program crashed or where. For this, use `thread backtrace all`. This will also show how the function where the program dumped core was called.
 
-[source,shell,subs="verbatim,quotes"]
+[source,bash,subs="verbatim,quotes"]
 ....
 (lldb) thread backtrace all
 * thread #1, name = 'progname', stop reason = signal SIGSEGV
@@ -811,7 +811,7 @@ One of the neatest features about `lldb` is that it can attach to a program that
 
 To do that, start up another `lldb`, use `ps` to find the process ID for the child, and do
 
-[source,shell]
+[source,bash]
 ....
 (lldb) process attach -p pid
 ....
@@ -848,7 +848,7 @@ Starting with LLDB 12.0.0, remote debugging is supported on FreeBSD. This means
 
 To launch a new process to be debugged remotely, run `lldb-server` on the remote server by typing
 
-[source,shell]
+[source,bash]
 ....
 % lldb-server g host:port -- progname
 ....
@@ -857,14 +857,14 @@ The process will be stopped immediately after launching, and `lldb-server` will
 
 Start `lldb` locally and type the following command to connect to the remote server:
 
-[source,shell]
+[source,bash]
 ....
 (lldb) gdb-remote host:port
 ....
 
 `lldb-server` can also attach to a running process. To do that, type the following on the remote server:
 
-[source,shell]
+[source,bash]
 ....
 % lldb-server g host:port --attach pid-or-name
 ....
@@ -875,14 +875,14 @@ Start `lldb` locally and type the following command to connect to the remote ser
 
 Start up gdb by typing
 
-[source,shell]
+[source,bash]
 ....
 % gdb progname
 ....
 
 although many people prefer to run it inside Emacs. To do this, type:
 
-[source,shell]
+[source,bash]
 ....
  M-x gdb RET progname RET
 ....
@@ -893,7 +893,7 @@ Finally, for those finding its text-based command-prompt style off-putting, ther
 
 Compile the program with `-g` to get the most out of using `gdb`. It will work without, but will only display the name of the function currently running, instead of the source code. A line like:
 
-[source,shell]
+[source,bash]
 ....
 ... (no debugging symbols found) ...
 ....
@@ -930,7 +930,7 @@ This program sets i to be `5` and passes it to a function `bazz()` which prints
 
 Compiling and running the program displays
 
-[source,shell]
+[source,bash]
 ....
 % cc -g -o temp temp.c
 % ./temp
@@ -940,7 +940,7 @@ anint = 4231
 
 That was not what we expected! Time to see what is going on!
 
-[source,shell]
+[source,bash]
 ....
 % gdb temp
 GDB is free software and you are welcome to distribute copies of it
@@ -962,7 +962,7 @@ bazz (anint=4231) at temp.c:17			gdb displays stack frame
 
 Hang on a minute! How did anint get to be `4231`? Was it not set to `5` in `main()`? Let us move up to `main()` and have a look.
 
-[source,shell]
+[source,bash]
 ....
 (gdb) up					Move up call stack
 #1  0x1625 in main () at temp.c:11		gdb displays stack frame
@@ -996,7 +996,7 @@ A core file is basically a file which contains the complete state of the process
 
 To examine a core file, start up `gdb` in the usual way. Instead of typing `break` or `run`, type
 
-[source,shell]
+[source,bash]
 ....
 (gdb) core progname.core
 ....
@@ -1005,7 +1005,7 @@ If the core file is not in the current directory, type `dir /path/to/core/file`
 
 The debugger should display something like this:
 
-[source,shell,subs="verbatim,quotes"]
+[source,bash,subs="verbatim,quotes"]
 ....
 % gdb [.filename]#progname#
 GDB is free software and you are welcome to distribute copies of it
@@ -1024,7 +1024,7 @@ In this case, the program was called [.filename]#progname#, so the core file is
 
 Sometimes it is useful to be able to see how a function was called, as the problem could have occurred a long way up the call stack in a complex program. `bt` causes `gdb` to print out a back-trace of the call stack:
 
-[source,shell]
+[source,bash]
 ....
 (gdb) bt
 #0  0x164a in bazz (anint=0x5) at temp.c:17
@@ -1041,7 +1041,7 @@ One of the neatest features about `gdb` is that it can attach to a program that
 
 To do that, start up another `gdb`, use `ps` to find the process ID for the child, and do
 
-[source,shell]
+[source,bash]
 ....
 (gdb) attach pid
 ....
@@ -1124,7 +1124,7 @@ Unfortunately, there is far too much here to explain it in detail; however there
 * Emacs already has a pre-defined function called `next-error`. In a compilation output window, this allows you to move from one compilation error to the next by doing `M-n`; we define a complementary function, `previous-error`, that allows you to go to a previous error by doing `M-p`. The nicest feature of all is that `C-c C-c` will open up the source file in which the error occurred and jump to the appropriate line.
 * We enable Emacs's ability to act as a server, so that if you are doing something outside Emacs and you want to edit a file, you can just type in
 +
-[source,shell]
+[source,bash]
 ....
 % emacsclient filename
 ....
@@ -1427,7 +1427,7 @@ Now, this is all very well if you only want to program in the languages already
 
 The first thing to do is find out if whizbang comes with any files that tell Emacs about the language. These usually end in [.filename]#.el#, short for "Emacs Lisp". For example, if whizbang is a FreeBSD port, we can locate these files by doing
 
-[source,shell]
+[source,bash]
 ....
 % find /usr/ports/lang/whizbang -name "*.el" -print
 ....
@@ -1436,14 +1436,14 @@ and install them by copying them into the Emacs site Lisp directory. On FreeBSD,
 
 So for example, if the output from the find command was
 
-[source,shell]
+[source,bash]
 ....
 /usr/ports/lang/whizbang/work/misc/whizbang.el
 ....
 
 we would do
 
-[source,shell]
+[source,bash]
 ....
 # cp /usr/ports/lang/whizbang/work/misc/whizbang.el /usr/local/shared/emacs/site-lisp
 ....