Applied Bill Maltby's grammatic-fixes patch.

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

6 files changed, 38 insertions, 35 deletions

diff --git a/chapter02/aboutlfs.xml b/chapter02/aboutlfs.xml
index 5dea03e3a..1c15be452 100644
--- a/chapter02/aboutlfs.xml
+++ b/chapter02/aboutlfs.xml
@@ -9,7 +9,7 @@ is mounted. How to create and where to mount the partition will be
 explained in full detail in Chapter 4. For example, let's assume that 
 the LFS partition is mounted on /mnt/lfs.</para>
 
-<para>For example when you are told to run a command like
+<para>When you are told to run a command like
 <userinput>./configure --prefix=$LFS/static</userinput> you actually have to
 execute <userinput>./configure --prefix=/mnt/lfs/static</userinput>.</para>
 
@@ -22,8 +22,11 @@ This way $LFS can be entered literally instead of replacing it with
 
 <para><screen><userinput>export LFS=/mnt/lfs</userinput></screen></para>
 
-<para>Now, if you are told to run a command like <userinput>./configure
---prefix=$LFS/static</userinput> you can type that literally. Your shell will
+<para>Now, if you are told to run a command like </para>
+
+<para><screen><userinput>./configure --prefix=$LFS/static</userinput></screen></para>
+
+<para>you can type that literally. Your shell will
 replace $LFS with /mnt/lfs when it processes the command line (meaning
 when you hit enter after having typed the command).</para>
 
diff --git a/chapter02/aboutsbus.xml b/chapter02/aboutsbus.xml
index f43859584..c6ad47071 100644
--- a/chapter02/aboutsbus.xml
+++ b/chapter02/aboutsbus.xml
@@ -6,7 +6,7 @@
 of identifying how long a package takes to compile. Why don't we use normal
 times like anybody else?</para>
 
-<para>The biggest problem is that times cannot be acurate, not even a
+<para>The biggest problem is that times cannot be accurate, not even a
 little bit. So many people install LFS on so many different systems, the
 times it takes to compile something varies too much. One package may take
 20 minutes on one system, but that same package may take 3 days on another
@@ -22,9 +22,8 @@ fairly consistent among a lot of different systems. So multiply 9.5 by the
 number of seconds it takes for Bash to install (the SBU value) and you get
 a close approximation of how long GCC will take on your system.</para>
 
-<para>Note: SBUs don't work on SMP machines. We've seen that SBUs don't
-work well on SMP based machines. So all bets are off if you're lucky enough
-to have an SMP setup.</para>
+<para>Note: We've seen that SBUs don't work well on SMP based machines. So
+all bets are off if you're lucky enough to have an SMP setup.</para>
 
 </sect1>
 
diff --git a/chapter02/askforhelp.xml b/chapter02/askforhelp.xml
index e36f36b15..6fb4becec 100644
--- a/chapter02/askforhelp.xml
+++ b/chapter02/askforhelp.xml
@@ -4,9 +4,9 @@
 
 <para>If you encounter a problem while using this book, and your problem 
 is not listed in the FAQ, you will find that most of the people on Internet 
-Relay Chat (IRC) and on the mailing lists are willing to help you. (An 
+Relay Chat (IRC) and on the mailing lists are willing to help you. An 
 overview of the LFS mailing lists can be found in 
-<xref linkend="ch01-maillists"/>.) To assist us in diagnosing and solving
+<xref linkend="ch01-maillists"/>. To assist us in diagnosing and solving
 your problem, include as much relevant information as possible in your
 request for help.</para>
 
@@ -18,7 +18,7 @@ essential things to include in your request are:</para>
 
 <itemizedlist>
 <listitem><para>the version of the book you are using (being &version;),</para></listitem>
-<listitem><para>the package or section you are having problems with,</para></listitem>
+<listitem><para>the package or section giving you problems,</para></listitem>
 <listitem><para>the exact error message or symptom you are receiving,</para></listitem>
 <listitem><para>whether you have deviated from the book at all.</para></listitem>
 </itemizedlist>
@@ -34,8 +34,8 @@ help us to see other possible causes of your problem.)</para>
 
 <para>When something goes wrong during the stage where the configure
 script is run, look at the last lines of the
-<filename>config.log</filename>. This file contains possible errors
-encountered during configure which aren't always printed to the screen.
+<filename>config.log</filename>. This file may contain errors
+encountered during configure which weren't printed to the screen.
 Include those relevant lines if you decide to ask for help.</para>
 
 </sect2>
@@ -45,9 +45,9 @@ Include those relevant lines if you decide to ask for help.</para>
 
 <para>To help us find the cause of the problem, both screen output and
 the contents of various files are useful. The screen output from both
-the ./configure script and when make is run can be useful.  Don't
-blindly include the whole thing but on the other hand, don't include too
-little.  As an example, here is some screen output from make:</para>
+the ./configure script and the make run can be useful.  Don't blindly
+include the whole thing but on the other hand, don't include too little.
+As an example, here is some screen output from make:</para>
 
 <para><screen>gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\" 
 -DLOCALEDIR=\"/mnt/lfs/usr/share/locale\" -DLIBDIR=\"/mnt/lfs/usr/lib\" 
@@ -69,15 +69,15 @@ make: *** [all-recursive-am] Error 2</screen></para>
 says <screen>make [2]: *** [make] Error 1</screen> and onwards.  This
 isn't enough for us to diagnose the problem because it only tells us
 that <emphasis>something</emphasis> went wrong, not
-<emphasis>what</emphasis> went wrong.  The whole section as
-quoted above is what should be included to be helpful, because it
+<emphasis>what</emphasis> went wrong.  The whole section, as
+in the example above, is what should be included to be helpful, because it
 includes the command that was executed and the command's error
 message(s).</para>
 
 <para>An excellent article on asking for help on the Internet in general
 has been written by Eric S. Raymond.  It is available online at <ulink
 url="http://www.tuxedo.org/~esr/faqs/smart-questions.html"/>.
-Read and follow the hints in this document and you are much more likely
+Read and follow the hints in that document and you are much more likely
 to get a response to start with and also to get the help you actually
 need.</para>
 
diff --git a/chapter02/download.xml b/chapter02/download.xml
index d8ff18345..a3e1d990a 100644
--- a/chapter02/download.xml
+++ b/chapter02/download.xml
@@ -6,13 +6,14 @@
 packages that were downloaded are placed somewhere in $LFS/usr/src.</para>
 
 <para>While it doesn't matter at all where you save the downloaded
-packages, we recommend storing it at least on the LFS partition. This just
-makes sense because you would still have access to those files when you boot
-into the LFS system. $LFS/usr/src is just a logical place to store source
-code, but by no means a requirement. You may even want to create a
-subdirectory under $LFS/usr/src for tarball storage. That way you can
-separate tarballs from temporary build directories, but again that's up
-to you.</para>
+packages, we recommend storing it at least on the LFS partition. This
+just makes sense because you need to have access to those those files
+when you chroot to $LFS and when you boot into the LFS system, although
+access when booted to $LFS could be handled other ways. $LFS/usr/src is
+just a logical place to store source code, but by no means a requirement.
+You may even want to create a subdirectory under $LFS/usr/src for tarball
+storage. That way you can separate tarballs from temporary build
+directories, but again that's up to you.</para>
 
 <para>The next chapter contains a list of all the packages that need to be
 downloaded. The LFS partition isn't created yet, so you can't store it
diff --git a/chapter02/install.xml b/chapter02/install.xml
index 70f85bbba..b7a050ee6 100644
--- a/chapter02/install.xml
+++ b/chapter02/install.xml
@@ -38,7 +38,7 @@ works no matter how your host system decided to patch tar.</para>
 
 <para>If a file is just tar'ed, it is unpacked by running:</para>
 
-<para><screen><userinput>tar xvf filename.tar</userinput></screen></para>
+<para><screen><userinput>tar -xvf filename.tar</userinput></screen></para>
 
 <para>When an archive is unpacked, a new directory will be created under the
 current directory (and this book assumes that the archives are unpacked
@@ -49,7 +49,7 @@ archive and cd into the newly created directory.</para>
 
 <para>From time to time you will be dealing with single files such as patch
 files. These files are generally gzip'ed or bzip2'ed. Before such files
-can be used they need to be uncompressed first.</para>
+can be used they need to be uncompressed.</para>
 
 <para>If a file is gzip'ed, it is unpacked by running:</para>
 
@@ -63,10 +63,10 @@ can be used they need to be uncompressed first.</para>
 it: either the directory that contains the sources can be deleted, or it
 can be kept. We highly recommend deleting it. If you don't do this and
 try to re-use the same source later on in the book (for example re-using
-the source trees from Chapter 5 for use in Chapter 6), it may not work
+the source trees from Chapter 5 in Chapter 6), it may not work
 as you expect it to. Source trees from Chapter 5 will have your host
 distribution's settings, which don't always apply to the LFS system
-after you enter the chroot'ed environment. Even running something like
+after you enter the chroot environment. Even running something like
 <emphasis>make clean</emphasis> doesn't always guarantee a clean source
 tree.</para>
 
@@ -75,10 +75,10 @@ immediately after you have installed it, but keep the downloaded tarball
 available for when you need it again.</para>
 
 <para>There is one exception; the kernel source tree. Keep it around as you
-will need it later in this book when building a kernel. Nothing will use
-the kernel tree so the source tree won't be in your way.  If, however,
-you are short of disk space, you can remove the kernel tree and re-untar
-it later when required.</para>
+will need it later in this book when building a kernel. Nothing before then
+will use the kernel tree, so the source tree won't be in your way.  If,
+however, you are short of disk space, you can remove the kernel tree and
+re-untar it later when required.</para>
 
 </sect1>
 
diff --git a/chapter02/platform.xml b/chapter02/platform.xml
index d82910247..81fcd9024 100644
--- a/chapter02/platform.xml
+++ b/chapter02/platform.xml
@@ -2,8 +2,8 @@
 <title>Which Platform?</title>
 <?dbhtml filename="platform.html" dir="chapter02"?>
 
-<para>LFS intends to be as far as possible platform independent.  Having
-said that, the main LFS development work occurs on the x86 platform.  We
+<para>LFS intends to be, as far as possible, platform independent. Having
+said that, the main LFS development work occurs on the x86 platform. We
 attempt to include information where possible on differences for other
 platforms such as PPC.  If you come across a problem compiling which is
 not related to the x86 platform, still feel free to ask for help on the