Second round of edits for final release

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

6 files changed, 36 insertions, 37 deletions

diff --git a/chapter04/aboutlfs.xml b/chapter04/aboutlfs.xml
index b54671b77..e0f64fa5b 100644
--- a/chapter04/aboutlfs.xml
+++ b/chapter04/aboutlfs.xml
@@ -27,7 +27,7 @@ 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>Don't forget to check that <quote>$LFS</quote> is set whenever
+<para>Do not forget to check that <quote>$LFS</quote> 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>
 
diff --git a/chapter04/aboutsbus.xml b/chapter04/aboutsbus.xml
index 1100b6e20..85e283059 100644
--- a/chapter04/aboutsbus.xml
+++ b/chapter04/aboutsbus.xml
@@ -7,16 +7,16 @@
 <title>About SBUs</title>
 <?dbhtml filename="aboutsbus.html"?>
 
-<para>Most people would like to know beforehand approximately how long
+<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 <emphasis>Static Binutils Unit</emphasis> (SBU) measure will be
+the Static Binutils Unit (SBU) measure will be
 used instead.</para>
 
-<para>The SBU measure works like this?the first package to be compiled
+<para>The SBU measure works as follows. The first package to be compiled
 from this book is the statically-linked Binutils in <xref
 linkend="chapter-temporary-tools"/>.  The time it takes to compile
 this package is what will be referred to as the Static Binutils Unit
@@ -27,23 +27,23 @@ time.</para>
 SBUs. This means that if a system took 10 minutes to compile and
 install the static Binutils, it will take
 <emphasis>approximately</emphasis> 45 minutes to build this example
-package. Fortunately, most build times are much shorter than the one
+package. Fortunately, most build times are shorter than the one
 for Binutils.</para>
 
-<para>Please note that if the system compiler on the host is GCC-2 based, the
+<para>Please note that if the system compiler on the host is gcc-2.x based, the
 SBUs listed may be somewhat understated. This is because the SBU is
 based on the very first package, compiled with the old GCC, while the
 rest of the system is compiled with the newer GCC-&gcc-version; (which is
 known to be approximately 30 percent slower). SBUs are also not
-highly accurate for SMP-based machines.</para>
+highly accurate for Symmetric Multi-Processor (SMP)-based machines.</para>
 
 <para>To view actual timings for specific machines, we recommend
 <ulink url="&lfs-root;~bdubbs/"/>.</para>
 
-<para>In general, SBUs are inaccurate because they depend on many
-factors, not just the GCC version. The only reason they are provided
-is to give some kind of indication of how long it might take to
-install a package, but the numbers can be off by as much as dozens of
+<para>In general, SBUs are not very accurate because they depend on many
+factors, not just the GCC version. 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>
 
 </sect1>
diff --git a/chapter04/abouttestsuites.xml b/chapter04/abouttestsuites.xml
index 07d4d07b1..01428a264 100644
--- a/chapter04/abouttestsuites.xml
+++ b/chapter04/abouttestsuites.xml
@@ -8,15 +8,15 @@
 <?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 ?sanity
-check? indicating that everything compiled correctly. A test suite
+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?GCC, Binutils, and
-Glibc?are of the utmost importance due to their central role in a
+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>
@@ -43,7 +43,7 @@ linkend="chapter-temporary-tools"/>.</para>
 
 <para>Sometimes package test suites will give false failures. Consult
 the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these
-failures are normal. This site is valid for all tests throughout this
+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 817e2ee51..6e03ccc78 100644
--- a/chapter04/addinguser.xml
+++ b/chapter04/addinguser.xml
@@ -4,7 +4,7 @@
   %general-entities;
 ]>
 <sect1 id="ch-tools-addinguser">
-<title>Adding the lfs User</title>
+<title>Adding the LFS User</title>
 <?dbhtml filename="addinguser.html"?>
 
 <para>When logged in as user <emphasis>root</emphasis>, making a
@@ -32,7 +32,7 @@ useradd -s /bin/bash -g lfs -m -k /dev/null lfs</userinput></screen>
 
 <varlistentry>
 <term><parameter>-g lfs</parameter></term>
-<listitem><para>This adds user <emphasis>lfs</emphasis> to group
+<listitem><para>This option adds user <emphasis>lfs</emphasis> to group
 <emphasis>lfs</emphasis></para></listitem>
 </varlistentry>
 
@@ -52,16 +52,16 @@ the special null device.</para></listitem>
 
 <varlistentry>
 <term><parameter>lfs</parameter></term>
-<listitem><para>The actual name for the created group and
+<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
+logged in as <emphasis>root</emphasis>, which does not require the
 <emphasis>lfs</emphasis> user to have a
-password in that case), give <emphasis>lfs</emphasis> a password:</para>
+password), give <emphasis>lfs</emphasis> a password:</para>
 
 <screen><userinput>passwd lfs</userinput></screen>
 
@@ -72,7 +72,7 @@ password in that case), give <emphasis>lfs</emphasis> a password:</para>
 <screen><userinput>chown lfs $LFS/tools</userinput></screen>
 
 <para>If a separate working directory was created as suggested, give
-user lfs ownership of this directory too:</para>
+user lfs ownership of this directory:</para>
 
 <screen><userinput>chown lfs $LFS/sources</userinput></screen>
 
diff --git a/chapter04/creatingtoolsdir.xml b/chapter04/creatingtoolsdir.xml
index 8528aafaa..de832f791 100644
--- a/chapter04/creatingtoolsdir.xml
+++ b/chapter04/creatingtoolsdir.xml
@@ -16,8 +16,7 @@ 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"/>), which could be a very bad
-thing.</para>
+linkend="chapter-temporary-tools"/>).</para>
 
 <para>Create the required directory by running the following as
 <emphasis>root</emphasis>:</para>
diff --git a/chapter04/settingenviron.xml b/chapter04/settingenviron.xml
index 93dabee79..d364e74aa 100644
--- a/chapter04/settingenviron.xml
+++ b/chapter04/settingenviron.xml
@@ -4,7 +4,7 @@
   %general-entities;
 ]>
 <sect1 id="ch-tools-settingenviron">
-<title>Setting up the environment</title>
+<title>Setting Up the Environment</title>
 <?dbhtml filename="settingenvironment.html"?>
 
 <para>Set up a good working environment by creating two new startup
@@ -16,9 +16,9 @@ following command to create a new <filename>.bash_profile</filename>:</para>
 exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
 EOF</userinput></screen>
 
-<para>Normally when logged on as user <emphasis>lfs</emphasis>, the
-initial shell is a <emphasis>login</emphasis> shell which reads the
-<filename>/etc/profile</filename> of your host (probably containing
+<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
@@ -28,7 +28,7 @@ with a new one with a completely empty environment, except for the
 <emphasis>PS1</emphasis> 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 enforcing a clean environment.</para>
+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
@@ -47,15 +47,15 @@ EOF</userinput></screen>
 
 <para>The <command>set +h</command> command turns off
 <command>bash</command>'s hash function. Hashing is
-ordinarily a useful feature -- bash uses a hash table to remember the
+ordinarily a useful feature&mdash;bash uses a hash table to remember the
 full pathnames of executable files to avoid searching the PATH time
-and time again to find the same executable. However, the new tools
+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 PATH when a program is
-requested to be run. As such, the shell will find our newly compiled
+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 (name wise) in a different location.</para>
+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
@@ -72,15 +72,15 @@ conventions of a specified country.  If the host system uses a version
 of Glibc older than 2.2.4, having LC_ALL 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. By setting <emphasis>LC_ALL</emphasis> to <quote>POSIX</quote>
-or <quote>C</quote> (the two are equivalent), we ensure that
+later. Setting <emphasis>LC_ALL</emphasis> 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 PATH, all the programs installed in <xref
 linkend="chapter-temporary-tools"/> are picked up by the shell
-imemdiately after their installation. This coupled with the fact that
-hashing has been turned off, there is no risk that old programs from
+immediately after their installation. This, combined with turning off 
+hashing, limits the risk that old programs from
 the host are being used when they should not be used any
 longer.</para>