AsciiDoc text replacement: non-escaped ' -- '

https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#text-replacements
notes that text replacement may occur where

 --

– is between two word characters, between a word character and a
line boundary, or flanked by spaces. The replacement:

 —

– an em dash.

The ripgrep command below helped to identify two editions of the
FreeBSD Developers' Handbook in which an escape charater was required.

rg '`.* -- .*`' /usr/doc

Whilst here: full stops, and one sentence per line for the affected
subsection of the zh-tw translation of the book.

https://bugs.freebsd.org/269679
PR:                      269679
Pull request: https://github.com/freebsd/freebsd-doc/pull/113

2 files changed, 13 insertions, 5 deletions

diff --git a/documentation/content/en/books/developers-handbook/tools/_index.adoc b/documentation/content/en/books/developers-handbook/tools/_index.adoc
index 92c48a7656..bba5b1636a 100644
--- a/documentation/content/en/books/developers-handbook/tools/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/tools/_index.adoc
@@ -884,7 +884,7 @@ In "the good old days", programmers had to print out hex listings of core files
 Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called [.filename]#progname.core# instead of just [.filename]#core#, to make it clearer which program a core file belongs to.
 
 To examine a core file, specify the name of the core file in addition to the program itself.
-Instead of starting up `lldb` in the usual way, type `lldb -c _progname_.core -- _progname_`
+Instead of starting up `lldb` in the usual way, type `lldb -c _progname_.core \-- _progname_`.
 
 The debugger will display something like this:
 
diff --git a/documentation/content/zh-tw/books/developers-handbook/tools/_index.adoc b/documentation/content/zh-tw/books/developers-handbook/tools/_index.adoc
index ce490709d9..973568c9b7 100644
--- a/documentation/content/zh-tw/books/developers-handbook/tools/_index.adoc
+++ b/documentation/content/zh-tw/books/developers-handbook/tools/_index.adoc
@@ -792,9 +792,12 @@ The `lldb` command displays the stack frame every time we go into or out of a fu
 
 ==== Examining a Core File with lldb
 
-A core file is basically a file which contains the complete state of the process when it crashed. In "the good old days", programmers had to print out hex listings of core files and sweat over machine code manuals, but now life is a bit easier. Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called [.filename]#progname.core# instead of just [.filename]#core#, to make it clearer which program a core file belongs to.
+A core file is basically a file which contains the complete state of the process when it crashed.
+In "the good old days", programmers had to print out hex listings of core files and sweat over machine code manuals, but now life is a bit easier.
+Incidentally, under FreeBSD and other 4.4BSD systems, a core file is called [.filename]#progname.core# instead of just [.filename]#core#, to make it clearer which program a core file belongs to.
 
-To examine a core file, specify the name of the core file in addition to the program itself. Instead of starting up `lldb` in the usual way, type `lldb -c _progname_.core -- _progname_`
+To examine a core file, specify the name of the core file in addition to the program itself.
+Instead of starting up `lldb` in the usual way, type `lldb -c _progname_.core \-- _progname_`.
 
 The debugger will display something like this:
 
@@ -806,7 +809,10 @@ Core file '/home/pauamma/tmp/[.filename]#progname.core#' (x86_64) was loaded.
 (lldb)
 ....
 
-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.
+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"]
 ....
@@ -818,7 +824,9 @@ In this case, the program was called [.filename]#progname#, so the core file is
 (lldb)
 ....
 
-`SIGSEGV` indicates that the program tried to access memory (run code or read/write data usually) at a location that does not belong to it, but does not give any specifics. For that, look at the source code at line 10 of file temp2.c, in `bazz()`. The backtrace also says that in this case, `bazz()` was called from `main()`.
+`SIGSEGV` indicates that the program tried to access memory (run code or read/write data usually) at a location that does not belong to it, but does not give any specifics.
+For that, look at the source code at line 10 of file temp2.c, in `bazz()`.
+The backtrace also says that in this case, `bazz()` was called from `main()`.
 
 ==== Attaching to a Running Program with lldb