pill 20: fix a few typos

+ add a few missing words
+ pick the lowercase spelling for `stdenv` and use it consistenly
+ reword a sentence that I had a hard time understanding
+ fix the path of the second nix expression to be included

pills/20-basic-dependencies-and-hooks.xml

@@ -8,8 +8,8 @@
 
   <para>
     Welcome to the 20th Nix pill.
-    In the previous <link linkend="fundamentals-of-stdenv">19th</link> pill we introduced Nixpkgs' Stdenv, including <filename>setup.sh</filename> script, <filename>default-builder.sh</filename> helper script, and <literal>stdenv.mkDerivation</literal> builder.
-    We focused on how stdenv is put together, and how it's used, an a bit about the phases of <function>genericBuild</function>.
+    In the previous <link linkend="fundamentals-of-stdenv">19th</link> pill we introduced Nixpkgs' stdenv, including <filename>setup.sh</filename> script, <filename>default-builder.sh</filename> helper script, and <literal>stdenv.mkDerivation</literal> builder.
+    We focused on how stdenv is put together, and how it's used, and a bit about the phases of <function>genericBuild</function>.
   </para>
 
   <para>
@@ -26,7 +26,7 @@
     The Nix pills before this one have used the most recent version of Nixpkgs when discussing it.
     But the dependencies and hooks infrastructure has for a few years been increasingly complicated to support cross compilation, with a final boost of complexity in recently in 2017.
     While the added mechanism shouldn't be too confusing after the core concepts are taught, they just get in the way before, so this Nix Pill will go all the way back to 2009 with commit <link xlink:href="https://github.com/nixos/nixpkgs/tree/6675f0a52c0962042a1000c7f20e887d0d26ae25">6675f0a5</link>.
-    This is the last version of Stdenv before extra dependency and hook types for cross compilation were created.
+    This is the last version of stdenv before extra dependency and hook types for cross compilation were created.
   </para>
 
   <section>
@@ -62,15 +62,15 @@
       The <varname>buildInputs</varname> covers direct dependencies, but what about indirect dependencies where one package needs a second package which needs a third?
       Nix itself handles this just fine, understanding various dependency <firstterm>closures</firstterm> as covered in previous builds.
       But what about the conveniences that <varname>buildInputs</varname> provides, namely accumulating in <envar>pkgs</envar> environment variable and inclusion of <filename><replaceable>pkg</replaceable>/bin</filename> directories on the <envar>PATH</envar>?
-      For this, Stdenv provides the <varname>propagatedBuildInputs</varname>:
-      <screen><xi:include href="./20/two-hellos.nix" parse="text" /></screen>
+      For this, stdenv provides the <varname>propagatedBuildInputs</varname>:
+      <screen><xi:include href="./20/three-hellos.nix" parse="text" /></screen>
       See how the intermediate package has a <varname>propagatedBuildInputs</varname> dependency, but the wrapper only needs a <varname>buildInputs</varname> dependency on the intermediary.
     </para>
 
     <para>
       How does this work?
       You might think we do something in Nix, but actually its done not at eval time but at build time in bash.
-      lets look at part of the <function>fixupPhase</function> of Stdenv:
+      lets look at part of the <function>fixupPhase</function> of stdenv:
 
       <screen><xi:include href="./20/propagated-build-inputs-0.bash" parse="text" /></screen>
 
@@ -108,8 +108,8 @@
       <varname>propagatedBuildInputs</varname> can actually be seen as an example of this:
       packages using that are effectively "injecting" those dependencies as extra <varname>buildInputs</varname> in their downstream dependents.
 
-      But in general, a dependency might to affect the packages it depends on in arbitrary ways.
-      <emphasis>arbitrary</emphasis> is the key word here
+      But in general, a dependency might affect the packages it depends on in arbitrary ways.
+      <emphasis>Arbitrary</emphasis> is the key word here.
       We could teach <filename>setup.sh</filename> things about upstream packages like <filename><replaceable>pkg</replaceable>/nix-support/propagated-build-inputs</filename>, but not arbitrary interactions.
     </para>
 
@@ -118,7 +118,7 @@
       In nixpkgs, a "hook" is basically a bash callback, and a setup hook is no exception.
       Let's look at the last part of <function>findInputs</function> we haven't covered:
       <screen><xi:include href="./20/setup-hooks-0.bash" parse="text" /></screen>
-      If a package includes the path <filename><replaceable>pkg</replaceable>/nix-support/setup-hook</filename>, it will be sourced by any Stdenv-based build including that as a dependency.
+      If a package includes the path <filename><replaceable>pkg</replaceable>/nix-support/setup-hook</filename>, it will be sourced by any stdenv-based build including that as a dependency.
     </para>
 
     <para>
@@ -156,11 +156,11 @@
     <para>
       The other half of <function>addToEnv</function> is:
       <screen><xi:include href="./20/env-hooks-0.bash" parse="text" /></screen>
-      See how for every package we iterate through the contents of <varname>envHooks</varname>, and apply every function within to the package in question.
-      The idea is one can write a setup hook like:
+      Functions listed in <varname>envHooks</varname> are applied to every package passed to <function>addToEnv</function>.
+      One can write a setup hook like:
       <screen><xi:include href="./20/env-hooks-1.bash" parse="text" /></screen>
       and if one dependency has that setup hook then all of them will be so <command>echo</command>ed.
-      Allowing dependencies to learn about their <emphasis>sibling</emphasis> dependencies is exactly what compiler need.
+      Allowing dependencies to learn about their <emphasis>sibling</emphasis> dependencies is exactly what compilers need.
     </para>
 
   </section>
@@ -169,7 +169,7 @@
     <title>Next pill...</title>
     <para>
       ...I'm not sure!
-      We could talk the additional dependency types and hooks which cross compilation necessitates, building on our knowledge here to cover stdenv as it works today.
+      We could talk about the additional dependency types and hooks which cross compilation necessitates, building on our knowledge here to cover stdenv as it works today.
       We could talk about how nixpkgs is bootstrapped.
       Or we could talk about how <varname>localSystem</varname> and <varname>crossSystem</varname> are elaborated into the <varname>buildPlatform</varname>, <varname>hostPlatform</varname>, and <varname>targetPlatform</varname> each bootstrapping stage receives.
       Let us know which most interests you!