Some small tweaks to example setup documentation.

doc/example.txt

@@ -5,7 +5,7 @@ This document will explain how we have things setup at the University of
 Minnesota's Computer Science Department, where we have have been using 
 modules for over 20 years.  It may not be the best setup but it will 
 give you an idea of what you need to think about when creating your 
-environment.  Note many of these things are interdependant.  How
+environment.  Note many of these things are interdependent.  How
 you setup your template user (Section 1) will depend on your 
 Layout (Section 05).
 
@@ -37,7 +37,7 @@ It's a balancing act that you will have to learn over time.
 
 02. Resetenv
 Users will eventually mess up their environment.  It's good to have a
-way to get back to a known starting point.  In modules/contrib/scripts/
+way to get back to a known good starting point.  In modules/contrib/scripts/
 we have a script we use "resetenv" which will allow users to backup
 their current '.*' files and then copy over the defaults from ~template.
 So that they can hopefully get back to a known working state.
@@ -63,10 +63,10 @@ we break things down first by OS, then by arch, and then sysname if needed.
 When adding a path to an environment variable use append-path
 only use prepend-path when absolutely needed.  If all of your modules work
 the same way it will be much easier for users to figure things out.
-On our linux systems we use prepend-path for the gcc module so that we can
+On our Linux systems we use prepend-path for the gcc module so that we can
 override the system default version of gcc, otherwise we would use append-path.
 
-Avoid setting LD_LIBRARY_PATH unless absolutly needed.  If your setting it
+Avoid setting LD_LIBRARY_PATH unless absolutely needed.  If your setting it
 you'll probably wind up with problems in the future.
 
 First setup a user modules directory, mkdir ~/.modules for example.
@@ -79,11 +79,11 @@ file, just like we did for the above two.  In general as time moves on
 you will have different versions of the software and if you name them
 you will be able to retire old versions without bothering the users.
 
-The best way is to use one of your existing modules and modify it to
-work for your new needs.  Once you have your module created it's important
-to test it on all of the distinct types of platforms you have.  After
-thats done you can copy the new module over to the systemwide modulefiles
-directory.
+The best way to create a new module, is to use one of your existing modules 
+and modify it to work for your new needs.  Once you have your module created 
+it's important to test it on all of the distinct types of platforms you want
+the module to function on.  After thats done, you can copy the new module 
+over to the system wide modulefiles directory.
 
 
 05. Distributing Modules/Revision control
@@ -96,16 +96,16 @@ REPOSOFMODULEFILES	/project/rdist/conf/opt/modules/modulefiles
 
 GLOBALMODULESINSTALL is where we have modules installed.  This is the live
 site for all of our users so we are very careful about making changes to this
-directory.  This directory is nfs shared to all of our client machines.
+directory.  This directory is NFS shared to all of our client machines.
 
 GLOBALMODULEFILES is where we have our live modules that the users use.  Again
 we are very careful about applying changes to this directory, and it is
-nfs shared to all of our clients.
+NFS shared to all of our clients.
 
 PERSONALMODULEFILES is where I store modules I am working on or testing.
 That way I can play with them and know that I'm not affecting users.
 
-PERSONALMODULESINSTALL is a seperate install of modules that I can use to
+PERSONALMODULESINSTALL is a separate install of modules that I can use to
 test the latest version of modules and make sure things are working before
 upgrading our GLOBALMODULESINSTALL.
 
@@ -118,11 +118,11 @@ clients through rsync.
 06. Testing a new version of modules command
 If you use a scheme similar to the above testing a new version of modules
 is really easy.  All you need to do is edit your .cshrc or .bashrc or
-whatever other file your using to initalize your modules environment.
+whatever other file your using to initialize your modules environment.
 and point it at PERSONALMODULESINSTALL instead of GLOBALMODULESINSTALL.
 In general what I do is do a "make test" with the global setup and
 then switch things to my PERSONALMODULESINSTALL and rerun the "make test"
-and compaire the results.  I usually leave my account on the PERSONAL
+and compare the results.  I usually leave my account on the PERSONAL
 version for a week or to to make sure there aren't any hidden bugs.
 Once the week is up, if there are no problems, I update the GLOBAL version.