Indented chapter 04.

git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@7275 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689

7 files changed, 292 insertions, 267 deletions

diff --git a/chapter04/aboutlfs.xml b/chapter04/aboutlfs.xml
index d97f634b0..14aec3126 100644
--- a/chapter04/aboutlfs.xml
+++ b/chapter04/aboutlfs.xml
@@ -1,35 +1,39 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <sect1 id="prepare-aboutlfs">
-<title>About $LFS</title>
-<?dbhtml filename="aboutlfs.html"?>
+  <?dbhtml filename="aboutlfs.html"?>
+
+  <title>About $LFS</title>
 
-<para>Throughout this book, the environment variable <envar>LFS</envar> will
-be used several times. It is paramount that this variable is always defined.
-It should be set to the mount point chosen for the LFS partition.
-Check that the <envar>LFS</envar> variable is set up properly with:</para>
+  <para>Throughout this book, the environment variable <envar>LFS</envar> will
+  be used several times. It is paramount that this variable is always defined.
+  It should be set to the mount point chosen for the LFS partition.
+  Check that the <envar>LFS</envar> variable is set up properly with:</para>
 
 <screen role="nodump"><userinput>echo $LFS</userinput></screen>
 
-<para>Make sure the output shows the path to the LFS partition's mount
-point, which is <filename class="directory">/mnt/lfs</filename> if the
-provided example was followed. If the output is incorrect, the
-variable can be set with:</para>
+  <para>Make sure the output shows the path to the LFS partition's mount
+  point, which is <filename class="directory">/mnt/lfs</filename> if the
+  provided example was followed. If the output is incorrect, the
+  variable can be set with:</para>
 
 <screen role="nodump"><userinput>export LFS=/mnt/lfs</userinput></screen>
 
-<para>Having this variable set is beneficial in that commands such as
-<command>mkdir $LFS/tools</command> can be typed literally. The shell
-will automatically replace <quote>$LFS</quote> with
-<quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
-processes the command line.</para>
+  <para>Having this variable set is beneficial in that commands such as
+  <command>mkdir $LFS/tools</command> can be typed literally. The shell
+  will automatically replace <quote>$LFS</quote> with
+  <quote>/mnt/lfs</quote> (or whatever the variable was set to) when it
+  processes the command line.</para>
 
-<para>Do not forget to check that <envar>$LFS</envar> is set whenever
-you leave and reenter the current working environment (as when doing a
-<quote>su</quote> to <emphasis>root</emphasis> or another user).</para>
+  <para>Do not forget to check that <envar>$LFS</envar> is set whenever
+  you leave and reenter the current working environment (as when doing a
+  <command>su</command> to <systemitem class="username">root</systemitem>
+  or another user).</para>
 
 </sect1>
 
diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml
index 28d83c01c..8383c6ffe 100644
--- a/chapter04/aboutsbus.xml
+++ b/chapter04/aboutsbus.xml
@@ -1,42 +1,45 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <sect1 id="prepare-aboutsbus">
-<title>About SBUs</title>
-<?dbhtml filename="aboutsbus.html"?>
-
-<para>Many people would like to know beforehand approximately how long
-it takes to compile and install each package. Because Linux From
-Scratch can be built on many different systems, it is impossible to
-provide accurate time estimates.  The biggest package (Glibc) will
-take approximately 20 minutes on the fastest systems, but could take
-up to three days on slower systems! Instead of providing actual times,
-the Standard Build Unit (SBU) measure will be
-used instead.</para>
-
-<para>The SBU measure works as follows. The first package to be compiled
-from this book is Binutils in <xref linkend="chapter-temporary-tools"/>.  The
-time it takes to compile this package is what will be referred to as the
-Standard Build Unit or SBU. All other compile times will be expressed relative
-to this time.</para>
-
-<para>For example, consider a package whose compilation time is 4.5
-SBUs. This means that if a system took 10 minutes to compile and
-install the first pass of Binutils, it will take
-<emphasis>approximately</emphasis> 45 minutes to build this example package.
-Fortunately, most build times are shorter than the one for Binutils.</para>
-
-<para>In general, SBUs are not entirely accurate because they depend on many
-factors, including the host system's version of GCC. Note that on Symmetric
-Multi-Processor (SMP)-based machines, SBUs are even less accurate.  They are
-provided here to give an estimate of how long it might take to install a
-package, but the numbers can vary by as much as dozens of minutes in some
-cases.</para>
-
-<para>To view actual timings for a number of specific machines, we recommend
-The LinuxFromScratch SBU Home Page at <ulink url="&lfs-root;~bdubbs/"/>.</para>
+  <?dbhtml filename="aboutsbus.html"?>
+
+  <title>About SBUs</title>
+
+  <para>Many people would like to know beforehand approximately how long
+  it takes to compile and install each package. Because Linux From
+  Scratch can be built on many different systems, it is impossible to
+  provide accurate time estimates. The biggest package (Glibc) will
+  take approximately 20 minutes on the fastest systems, but could take
+  up to three days on slower systems! Instead of providing actual times,
+  the Standard Build Unit (SBU) measure will be
+  used instead.</para>
+
+  <para>The SBU measure works as follows. The first package to be compiled
+  from this book is Binutils in <xref linkend="chapter-temporary-tools"/>. The
+  time it takes to compile this package is what will be referred to as the
+  Standard Build Unit or SBU. All other compile times will be expressed relative
+  to this time.</para>
+
+  <para>For example, consider a package whose compilation time is 4.5
+  SBUs. This means that if a system took 10 minutes to compile and
+  install the first pass of Binutils, it will take
+  <emphasis>approximately</emphasis> 45 minutes to build this example package.
+  Fortunately, most build times are shorter than the one for Binutils.</para>
+
+  <para>In general, SBUs are not entirely accurate because they depend on many
+  factors, including the host system's version of GCC. Note that on Symmetric
+  Multi-Processor (SMP)-based machines, SBUs are even less accurate. They are
+  provided here to give an estimate of how long it might take to install a
+  package, but the numbers can vary by as much as dozens of minutes in some
+  cases.</para>
+
+  <para>To view actual timings for a number of specific machines, we recommend
+  The LinuxFromScratch SBU Home Page at <ulink url="&lfs-root;~bdubbs/"/>.</para>
 
 </sect1>
 
diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml
index 19993637d..1a08bedea 100644
--- a/chapter04/abouttestsuites.xml
+++ b/chapter04/abouttestsuites.xml
@@ -1,50 +1,52 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <sect1 id="prepare-abouttestsuites">
-<title>About the Test Suites</title>
-<?dbhtml filename="abouttestsuites.html"?>
-
-<para>Most packages provide a test suite. Running the test suite for a
-newly built package is a good idea because it can provide a <quote>sanity
-check</quote> indicating that everything compiled correctly. A test suite
-that passes its set of checks usually proves that the package is
-functioning as the developer intended. It does not, however, guarantee
-that the package is totally bug free.</para>
-
-<para>Some test suites are more important than others. For example,
-the test suites for the core toolchain packages&mdash;GCC, Binutils, and
-Glibc&mdash;are of the utmost importance due to their central role in a
-properly functioning system. The test suites for GCC and Glibc can
-take a very long time to complete, especially on slower hardware, but
-are strongly recommended.</para>
-
-<note><para>Experience has shown that there is little to be gained
-from running the test suites in <xref
-linkend="chapter-temporary-tools"/>. There can be no escaping the fact
-that the host system always exerts some influence on the tests in that
-chapter, often causing inexplicable failures. Because the tools built
-in <xref linkend="chapter-temporary-tools"/> are temporary and
-eventually discarded, we do not recommend running the test suites in
-<xref linkend="chapter-temporary-tools"/> for the average reader. The
-instructions for running those test suites are provided for the
-benefit of testers and developers, but they are strictly
-optional.</para></note>
-
-<para>A common issue with running the test suites for Binutils and GCC
-is running out of pseudo terminals (PTYs). This can result in a high
-number of failing tests. This may happen for several reasons, but the
-most likely cause is that the host system does not have the
-<systemitem class="filesystem">devpts</systemitem> file system set up 
-correctly. This issue is discussed in greater detail in <xref
-linkend="chapter-temporary-tools"/>.</para>
-
-<para>Sometimes package test suites will fail, but for reasons which the
-developers are aware of and have deemed non-critical. Consult the logs located
-at <ulink url="&test-results;"/> to verify whether or not these failures are
-expected. This site is valid for all tests throughout this book.</para>
+  <?dbhtml filename="abouttestsuites.html"?>
 
-</sect1>
+  <title>About the Test Suites</title>
+
+  <para>Most packages provide a test suite. Running the test suite for a
+  newly built package is a good idea because it can provide a <quote>sanity
+  check</quote> indicating that everything compiled correctly. A test suite
+  that passes its set of checks usually proves that the package is
+  functioning as the developer intended. It does not, however, guarantee
+  that the package is totally bug free.</para>
+
+  <para>Some test suites are more important than others. For example,
+  the test suites for the core toolchain packages&mdash;GCC, Binutils, and
+  Glibc&mdash;are of the utmost importance due to their central role in a
+  properly functioning system. The test suites for GCC and Glibc can
+  take a very long time to complete, especially on slower hardware, but
+  are strongly recommended.</para>
 
+  <note>
+    <para>Experience has shown that there is little to be gained from running
+    the test suites in <xref linkend="chapter-temporary-tools"/>. There can be
+    no escaping the fact that the host system always exerts some influence on
+    the tests in that chapter, often causing inexplicable failures. Because
+    the tools built in <xref linkend="chapter-temporary-tools"/> are temporary
+    and eventually discarded, we do not recommend running the test suites in
+    <xref linkend="chapter-temporary-tools"/> for the average reader. The
+    instructions for running those test suites are provided for the benefit of
+    testers and developers, but they are strictly optional.</para>
+  </note>
+
+  <para>A common issue with running the test suites for Binutils and GCC
+  is running out of pseudo terminals (PTYs). This can result in a high
+  number of failing tests. This may happen for several reasons, but the
+  most likely cause is that the host system does not have the
+  <systemitem class="filesystem">devpts</systemitem> file system set up
+  correctly. This issue is discussed in greater detail in <xref
+  linkend="chapter-temporary-tools"/>.</para>
+
+  <para>Sometimes package test suites will fail, but for reasons which the
+  developers are aware of and have deemed non-critical. Consult the logs located
+  at <ulink url="&test-results;"/> to verify whether or not these failures are
+  expected. This site is valid for all tests throughout this book.</para>
+
+</sect1>
diff --git a/chapter04/addinguser.xml b/chapter04/addinguser.xml
index 7cb703824..5a1a2d3fa 100644
--- a/chapter04/addinguser.xml
+++ b/chapter04/addinguser.xml
@@ -1,90 +1,102 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <sect1 id="ch-tools-addinguser">
-<title>Adding the LFS User</title>
-<?dbhtml filename="addinguser.html"?>
-
-<para>When logged in as user <emphasis>root</emphasis>, making a single mistake
-can damage or destroy a system. Therefore, we recommend building the packages in
-this chapter as an unprivileged user. You could use your own user name, but to
-make it easier to set up a clean working environment, create a new user called
-<emphasis>lfs</emphasis> as a member of a new group (also named
-<emphasis>lfs</emphasis>) and use this user during the installation process. As
-<emphasis>root</emphasis>, issue the following commands to add the new
-user:</para>
+  <?dbhtml filename="addinguser.html"?>
+
+  <title>Adding the LFS User</title>
+
+  <para>When logged in as user <systemitem class="username">root</systemitem>,
+  making a single mistake can damage or destroy a system. Therefore, we
+  recommend building the packages in this chapter as an unprivileged user.
+  You could use your own user name, but to make it easier to set up a clean
+  working environment, create a new user called <systemitem
+  class="username">lfs</systemitem> as a member of a new group (also named
+  <systemitem class="groupname">lfs</systemitem>) and use this user during
+  the installation process. As <systemitem class="username">root</systemitem>,
+  issue the following commands to add the new user:</para>
 
 <screen><userinput>groupadd lfs
 useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
 
-<para>The meaning of the command line options:</para>
-
-<variablelist>
-<varlistentry>
-<term><parameter>-s /bin/bash</parameter></term>
-<listitem><para>This makes
-<command>bash</command> the default shell for user
-<emphasis>lfs</emphasis>.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>-g lfs</parameter></term>
-<listitem><para>This option adds user <emphasis>lfs</emphasis> to group
-<emphasis>lfs</emphasis>.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>-m</parameter></term>
-<listitem><para>This creates a home
-directory for <emphasis>lfs</emphasis>.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>-k /dev/null</parameter></term>
-<listitem><para>This parameter
-prevents possible copying of files from a skeleton directory (default
-is <filename class="directory">/etc/skel</filename>) by changing the input location to
-the special null device.</para></listitem>
-</varlistentry>
-
-<varlistentry>
-<term><parameter>lfs</parameter></term>
-<listitem><para>This is the actual name for the created group and
-user.</para></listitem>
-</varlistentry>
-</variablelist>
-
-<para>To log in as <emphasis>lfs</emphasis> (as opposed to switching
-to user <emphasis>lfs</emphasis> when
-logged in as <emphasis>root</emphasis>, which does not require the
-<emphasis>lfs</emphasis> user to have a
-password), give <emphasis>lfs</emphasis> a password:</para>
+  <variablelist>
+    <title>The meaning of the command line options:</title>
+
+    <varlistentry>
+      <term><parameter>-s /bin/bash</parameter></term>
+      <listitem>
+        <para>This makes <command>bash</command> the default shell for user
+        <systemitem class="username">lfs</systemitem>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>-g lfs</parameter></term>
+      <listitem>
+        <para>This option adds user <systemitem class="username">lfs</systemitem>
+        to group <systemitem class="groupname">lfs</systemitem>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>-m</parameter></term>
+      <listitem>
+        <para>This creates a home directory for <systemitem
+        class="username">lfs</systemitem>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>-k /dev/null</parameter></term>
+      <listitem>
+        <para>This parameter prevents possible copying of files from a skeleton
+        directory (default is <filename class="directory">/etc/skel</filename>)
+        by changing the input location to the special null device.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term><parameter>lfs</parameter></term>
+      <listitem>
+        <para>This is the actual name for the created group and user.</para>
+      </listitem>
+    </varlistentry>
+
+  </variablelist>
+
+  <para>To log in as <systemitem class="username">lfs</systemitem> (as opposed
+  to switching to user <systemitem class="username">lfs</systemitem> when logged
+  in as <systemitem class="username">root</systemitem>, which does not require
+  the <systemitem class="username">lfs</systemitem> user to have a password),
+  give <systemitem class="username">lfs</systemitem> a password:</para>
 
 <screen role="nodump"><userinput>passwd lfs</userinput></screen>
 
-<para>Grant <emphasis>lfs</emphasis> full access to
-<filename class="directory">$LFS/tools</filename> by making
-<emphasis>lfs</emphasis> the directory owner:</para>
+  <para>Grant <systemitem class="username">lfs</systemitem> full access to
+  <filename class="directory">$LFS/tools</filename> by making
+  <systemitem class="username">lfs</systemitem> the directory owner:</para>
 
 <screen><userinput>chown -v lfs $LFS/tools</userinput></screen>
 
-<para>If a separate working directory was created as suggested, give
-user <emphasis>lfs</emphasis> ownership of this directory:</para>
+  <para>If a separate working directory was created as suggested, give
+  user <systemitem class="username">lfs</systemitem> ownership of this
+  directory:</para>
 
 <screen><userinput>chown -v lfs $LFS/sources</userinput></screen>
 
-<para>Next, login as user <emphasis>lfs</emphasis>. This can be done
-via a virtual console, through a display manager, or with the
-following substitute user command:</para>
+  <para>Next, login as user <systemitem class="username">lfs</systemitem>.
+  This can be done via a virtual console, through a display manager, or with
+  the following substitute user command:</para>
 
-<screen><userinput>su - lfs</userinput></screen>
+<screen role="nodump"><userinput>su - lfs</userinput></screen>
 
-<para>The <quote><parameter>-</parameter></quote> instructs
-<command>su</command> to start a login shell as opposed to a non-login shell.
-The difference between these two types of shells can be found in detail in
-<filename>bash(1)</filename> and <command>info bash</command>.</para>
+  <para>The <quote><parameter>-</parameter></quote> instructs
+  <command>su</command> to start a login shell as opposed to a non-login shell.
+  The difference between these two types of shells can be found in detail in
+  <filename>bash(1)</filename> and <command>info bash</command>.</para>
 
 </sect1>
-
diff --git a/chapter04/chapter04.xml b/chapter04/chapter04.xml
index 689932619..b5ef385c6 100644
--- a/chapter04/chapter04.xml
+++ b/chapter04/chapter04.xml
@@ -1,18 +1,21 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <chapter id="chapter-final-preps" xreflabel="Chapter 4">
-<?dbhtml dir="chapter04"?>
-<title>Final Preparations</title>
-<?dbhtml filename="chapter04.html"?>
+  <?dbhtml dir="chapter04"?>
+  <?dbhtml filename="chapter04.html"?>
+
+  <title>Final Preparations</title>
 
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
-<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutlfs.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="creatingtoolsdir.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="addinguser.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="settingenviron.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="aboutsbus.xml"/>
+  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="abouttestsuites.xml"/>
 
 </chapter>
diff --git a/chapter04/creatingtoolsdir.xml b/chapter04/creatingtoolsdir.xml
index bed68fb17..50fa9aa25 100644
--- a/chapter04/creatingtoolsdir.xml
+++ b/chapter04/creatingtoolsdir.xml
@@ -1,46 +1,48 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <sect1 id="ch-tools-creatingtoolsdir">
-<title>Creating the $LFS/tools Directory</title>
-<?dbhtml filename="creatingtoolsdir.html"?>
-
-<para>All programs compiled in <xref
-linkend="chapter-temporary-tools"/> will be installed under <filename
-class="directory">$LFS/tools</filename> to keep them separate from the
-programs compiled in <xref linkend="chapter-building-system"/>. The
-programs compiled here are temporary tools and will not be a part of
-the final LFS system.  By keeping these programs in a separate
-directory, they can easily be discarded later after their use. This
-also prevents these programs from ending up in the host production
-directories (easy to do by accident in <xref
-linkend="chapter-temporary-tools"/>).</para>
-
-<para>Create the required directory by running the following as
-<emphasis>root</emphasis>:</para>
+  <?dbhtml filename="creatingtoolsdir.html"?>
+
+  <title>Creating the $LFS/tools Directory</title>
+
+  <para>All programs compiled in <xref linkend="chapter-temporary-tools"/>
+  will be installed under <filename class="directory">$LFS/tools</filename>
+  to keep them separate from the programs compiled in <xref
+  linkend="chapter-building-system"/>. The programs compiled here are
+  temporary tools and will not be a part of the final LFS system. By keeping
+  these programs in a separate directory, they can easily be discarded later
+  after their use. This also prevents these programs from ending up in the
+  host production directories (easy to do by accident in <xref
+  linkend="chapter-temporary-tools"/>).</para>
+
+  <para>Create the required directory by running the following as
+  <systemitem class="username">root</systemitem>:</para>
 
 <screen><userinput>mkdir -v $LFS/tools</userinput></screen>
 
-<para>The next step is to create a <filename class="symlink">/tools</filename> 
-symlink on the host system.  This will point to the newly-created directory on
-the LFS partition. Run this command as <emphasis>root</emphasis> as
-well:</para>
+  <para>The next step is to create a <filename class="symlink">/tools</filename>
+  symlink on the host system. This will point to the newly-created directory on
+  the LFS partition. Run this command as <systemitem
+  class="username">root</systemitem> as well:</para>
 
 <screen><userinput>ln -sv $LFS/tools /</userinput></screen>
 
-<note><para>The above command is correct. The <command>ln</command> command has
-a few syntactic variations, so be sure to check <command>info coreutils ln</command> and
-<filename>ln(1)</filename> before reporting what you may think is an
-error.</para></note>
+  <note>
+    <para>The above command is correct. The <command>ln</command> command
+    has a few syntactic variations, so be sure to check
+    <command>info coreutils ln</command> and <filename>ln(1)</filename>
+    before reporting what you may think is an error.</para>
+  </note>
 
-<para>The created symlink enables the toolchain to be compiled so that
-it always refers to <filename class="directory">/tools</filename>,
-meaning that the compiler, assembler, and linker will work both in
-this chapter (when we are still using some tools from the host) and in
-the next (when we are <quote>chrooted</quote> to the LFS
-partition).</para>
+  <para>The created symlink enables the toolchain to be compiled so that it
+  always refers to <filename class="directory">/tools</filename>, meaning
+  that the compiler, assembler, and linker will work both in this chapter
+  (when we are still using some tools from the host) and in the next (when
+  we are <quote>chrooted</quote> to the LFS partition).</para>
 
 </sect1>
-
diff --git a/chapter04/settingenviron.xml b/chapter04/settingenviron.xml
index 574526392..561e30381 100644
--- a/chapter04/settingenviron.xml
+++ b/chapter04/settingenviron.xml
@@ -1,40 +1,41 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
   <!ENTITY % general-entities SYSTEM "../general.ent">
   %general-entities;
 ]>
+
 <sect1 id="ch-tools-settingenviron">
-<title>Setting Up the Environment</title>
-<?dbhtml filename="settingenvironment.html"?>
+  <?dbhtml filename="settingenvironment.html"?>
+
+  <title>Setting Up the Environment</title>
 
-<para>Set up a good working environment by creating two new startup
-files for the <command>bash</command> shell. While logged in as user
-<emphasis>lfs</emphasis>, issue the
-following command to create a new <filename>.bash_profile</filename>:</para>
+  <para>Set up a good working environment by creating two new startup files
+  for the <command>bash</command> shell. While logged in as user
+  <systemitem class="username">lfs</systemitem>, issue the following command
+  to create a new <filename>.bash_profile</filename>:</para>
 
 <screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
 <literal>exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash</literal>
 EOF</userinput></screen>
 
-<para>When logged on as user <emphasis>lfs</emphasis>, the
-initial shell is usually a <emphasis>login</emphasis> shell which reads the
-<filename>/etc/profile</filename> of the host (probably containing
-some settings and environment variables) and then
-<filename>.bash_profile</filename>. The <command>exec env
--i.../bin/bash</command> command in the
-<filename>.bash_profile</filename> file replaces the running shell
-with a new one with a completely empty environment, except for the
-<envar>HOME</envar>, <envar>TERM</envar>, and
-<envar>PS1</envar> variables. This ensures that no unwanted and
-potentially hazardous environment variables from the host system leak
-into the build environment. The technique used here achieves the goal
-of ensuring a clean environment.</para>
+  <para>When logged on as user <systemitem class="username">lfs</systemitem>,
+  the initial shell is usually a <emphasis>login</emphasis> shell which reads
+  the <filename>/etc/profile</filename> of the host (probably containing some
+  settings and environment variables) and then <filename>.bash_profile</filename>.
+  The <command>exec env -i.../bin/bash</command> command in the
+  <filename>.bash_profile</filename> file replaces the running shell with a new
+  one with a completely empty environment, except for the <envar>HOME</envar>,
+  <envar>TERM</envar>, and <envar>PS1</envar> variables. This ensures that no
+  unwanted and potentially hazardous environment variables from the host system
+  leak into the build environment. The technique used here achieves the goal of
+  ensuring a clean environment.</para>
 
-<para>The new instance of the shell is a <emphasis>non-login</emphasis>
-shell, which does not read the <filename>/etc/profile</filename> or
-<filename>.bash_profile</filename> files, but rather reads the
-<filename>.bashrc</filename> file instead. Create the
-<filename>.bashrc</filename> file now:</para>
+  <para>The new instance of the shell is a <emphasis>non-login</emphasis>
+  shell, which does not read the <filename>/etc/profile</filename> or
+  <filename>.bash_profile</filename> files, but rather reads the
+  <filename>.bashrc</filename> file instead. Create the
+  <filename>.bashrc</filename> file now:</para>
 
 <screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
 <literal>set +h
@@ -45,48 +46,46 @@ PATH=/tools/bin:/bin:/usr/bin
 export LFS LC_ALL PATH</literal>
 EOF</userinput></screen>
 
-<para>The <command>set +h</command> command turns off
-<command>bash</command>'s hash function. Hashing is ordinarily a useful 
-feature&mdash;<command>bash</command> uses a hash table to remember the
-full path of executable files to avoid searching the <envar>PATH</envar> time
-and again to find the same executable. However, the new tools
-should be used as soon as they are installed. By switching off the
-hash function, the shell will always search the <envar>PATH</envar> when a program is
-to be run. As such, the shell will find the newly compiled
-tools in <filename class="directory">$LFS/tools</filename> as soon as
-they are available without remembering a previous version of the same
-program in a different location.</para>
+  <para>The <command>set +h</command> command turns off
+  <command>bash</command>'s hash function. Hashing is ordinarily a useful
+  feature&mdash;<command>bash</command> uses a hash table to remember the
+  full path of executable files to avoid searching the <envar>PATH</envar>
+  time and again to find the same executable. However, the new tools should
+  be used as soon as they are installed. By switching off the hash function,
+  the shell will always search the <envar>PATH</envar> when a program is to
+  be run. As such, the shell will find the newly compiled tools in
+  <filename class="directory">$LFS/tools</filename> as soon as they are
+  available without remembering a previous version of the same program in a
+  different location.</para>
 
-<para>Setting the user file-creation mask (umask) to 022 ensures that newly
-created files and directories are only writable by their owner, but
-are readable and executable by anyone (assuming default modes are used
-by the open(2) system call, new files will end up with permission mode
-644 and directories with mode 755).</para>
+  <para>Setting the user file-creation mask (umask) to 022 ensures that newly
+  created files and directories are only writable by their owner, but are
+  readable and executable by anyone (assuming default modes are used by the
+  <function>open(2)</function> system call, new files will end up with permission
+  mode 644 and directories with mode 755).</para>
 
-<para>The <envar>LFS</envar> variable should be set to the
-chosen mount point.</para>
+  <para>The <envar>LFS</envar> variable should be set to the chosen mount
+  point.</para>
 
-<para>The <envar>LC_ALL</envar> variable controls the
-localization of certain programs, making their messages follow the
-conventions of a specified country.  If the host system uses a version
-of Glibc older than 2.2.4, having <envar>LC_ALL</envar> set to something other than
-<quote>POSIX</quote> or <quote>C</quote> (during this chapter) may
-cause issues if you exit the chroot environment and wish to return
-later. Setting <envar>LC_ALL</envar> to <quote>POSIX</quote>
-or <quote>C</quote> (the two are equivalent) ensures that
-everything will work as expected in the chroot environment.</para>
+  <para>The <envar>LC_ALL</envar> variable controls the localization of certain
+  programs, making their messages follow the conventions of a specified country.
+  If the host system uses a version of Glibc older than 2.2.4, having
+  <envar>LC_ALL</envar> set to something other than <quote>POSIX</quote> or
+  <quote>C</quote> (during this chapter) may cause issues if you exit the chroot
+  environment and wish to return later. Setting <envar>LC_ALL</envar> to
+  <quote>POSIX</quote> or <quote>C</quote> (the two are equivalent) ensures that
+  everything will work as expected in the chroot environment.</para>
 
-<para>By putting <filename class="directory">/tools/bin</filename> ahead of the
-standard <envar>PATH</envar>, all the programs installed in <xref
-linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
-their installation. This, combined with turning off hashing, limits the risk
-that old programs are used from the host when the same programs are available in
-the chapter 5 environment.</para>
+  <para>By putting <filename class="directory">/tools/bin</filename> ahead of the
+  standard <envar>PATH</envar>, all the programs installed in <xref
+  linkend="chapter-temporary-tools"/> are picked up by the shell immediately after
+  their installation. This, combined with turning off hashing, limits the risk
+  that old programs are used from the host when the same programs are available in
+  the chapter 5 environment.</para>
 
-<para>Finally, to have the environment fully prepared for building the
-temporary tools, source the just-created user profile:</para>
+  <para>Finally, to have the environment fully prepared for building the
+  temporary tools, source the just-created user profile:</para>
 
 <screen><userinput>source ~/.bash_profile</userinput></screen>
 
 </sect1>
-