doc: fix some typos found with codespell

xdelaruelle · xdelaruelle · commit f13599b9b1b3 · 2025-03-03T07:28:22.000+01:00
The codespell [1] tool is very convenient to help spotting typos in documentation files. It helps me a lot everyday thus I thought it may be of interest for the Lmod project. Here I have applied codespell on the "docs" directory and fixes the typos it found. [1] https://github.com/codespell-project/codespell
diff --git a/docs/source/030_installing.rst b/docs/source/030_installing.rst
@@ -117,7 +117,7 @@ Using Your Package Manager for Ubuntu or Debian systems
 For modern debian and debian derivatives, you can get the necessary
 dependencies by executing the following commands.  Note that for this
 to work you may need to repair your /etc/apt/sources.list.  Check to
-see if your sources.list file as uncommmented "deb-src" lines.  Once
+see if your sources.list file as uncommented "deb-src" lines.  Once
 this is correct, please execute the following lines::
 
     $ sudo apt update
diff --git a/docs/source/040_FAQ.rst b/docs/source/040_FAQ.rst
@@ -277,7 +277,7 @@ scripts such as job submission scripts?
 Why do modules sometimes get loaded when I execute ``module use <path>``?
 
    A main principal is that when $MODULEPATH changes, Lmod checks all
-   the currently loaded modules. If any of thoses modules would not
+   the currently loaded modules. If any of those modules would not
    have been chosen then each is swapped for the new choice.
 
 How to use module commands inside a Makefile?
@@ -322,7 +322,7 @@ What to do if new modules are missing when doing ``module avail``?
 How to edit a modulefile?
 
    Lmod does not provide a way to directly edit modulefiles.
-   Typically modulefiles are owned by the system so cannot be editted
+   Typically modulefiles are owned by the system so cannot be edited
    by users.  However, Lmod does provide a convenient way to locate
    modules which could be used for a bash/zsh shell function::
 
diff --git a/docs/source/050_lua_modulefiles.rst b/docs/source/050_lua_modulefiles.rst
@@ -250,7 +250,7 @@ The entries below describe several useful commands that come with Lmod that can
 **mode** ():
     Returns the string "load" when a modulefile is being loaded,
     "unload" when unloading, and "spider" when a modulefile is
-    processed builting the spider cache which is used by *module
+    processed building the spider cache which is used by *module
     avail* and *module spider*.
 
 **isloaded** ("NAME"):
diff --git a/docs/source/052_Environment_Variables.rst b/docs/source/052_Environment_Variables.rst
@@ -8,7 +8,7 @@ Environment variables defined by Lmod startup files
 **LMOD_CMD** : The path to the installed lmod command.
 
 **LMOD_DIR** : The directory that contains the installed lmod
-    command.  This environment variable is usefull for running the
+    command.  This environment variable is useful for running the
     **spider** command: i.e. $LMOD_DIR/spider.  This is the libexec directory
 
 **LMOD_PKG** : This the path the directory that contains the libexec,
diff --git a/docs/source/055_module_names.rst b/docs/source/055_module_names.rst
@@ -45,7 +45,7 @@ fullName == sn/version
 
 The fullName of a modulefile is complete name which is made of two
 parts: sn and version.  The sn is the shortname and represents the
-minumum name that can be used to specify a module.  So for the
+minimum name that can be used to specify a module.  So for the
 ``gcc/7.1`` modulefile.  The fullName is ``gcc/7.1`` and the sn is
 ``gcc`` and the version is ``7.1``.  This naming convention is known
 as NAME/VERSION and is abbreviated N/V.  There are two more complicated
@@ -83,7 +83,7 @@ packages be named: ``bio/bowtie/3.4`` or ``bio/tophat/2.7``.  When the
 fullName is ``bio/bowtie/3.4`` then the sn for is ``bio/bowtie`` and the
 version is ``3.4``.
 
-Sites should think carefully about chosing to using C/N/V.  This can
+Sites should think carefully about choosing to using C/N/V.  This can
 make it easier for users to know which modules provide say physics, 
 chemistry or biology applications but it does lead to great deal more
 typing of which tab completion provided by the bash or zsh shells can
@@ -117,7 +117,7 @@ Sites can mix N/V and C/N/V layouts, Lmod will be able to decide the
 sn and versions by walking directory tree. In general, the fullName,
 will be divided into directories names to become the sn and the
 version will be the file.  So for the fullName ``bio/tophat/7.2`` the
-directores bio and tophat become the sn, ``bio/tophat`` and the
+directories bio and tophat become the sn, ``bio/tophat`` and the
 version is ``7.2``.
 
 Lmod supports as many directory levels as site likes.  For example, a
diff --git a/docs/source/110_lmod_mpi_parallel_filesystem.rst b/docs/source/110_lmod_mpi_parallel_filesystem.rst
@@ -13,7 +13,7 @@ this timeout problem for mpi programs that execute more than 1000
 nodes, but when this problem occurs will depend on relative speeds of
 the network and the parallel filesystem.
 
-It is helpful to outline the proceedure that we use at TACC to start a
+It is helpful to outline the procedure that we use at TACC to start a
 job on a compute node for a user 
 
 #. The bash user submits a job to the scheduler.
@@ -86,7 +86,7 @@ submission script::
     #SBATCH ...
 
     module load intel mvapich2
-    ibrun ./my_mpi_program        # start parallel executation.
+    ibrun ./my_mpi_program        # start parallel execution.
 
 Note that the total environment is passed by our parallel job starter
 ibrun.  So there is no need for a user's ~/bashrc or similar file to
diff --git a/docs/source/120_shared_home_directories.rst b/docs/source/120_shared_home_directories.rst
@@ -9,7 +9,7 @@ across their cluster.  If a site has more than one cluster, they may
 chose to have a separate home directory for each cluster.  Some sites
 may wish to have multiple clusters share a single home directory.
 While this strategy has some advantages, it complicates things for
-your users and adminstrators.  If your site has a single home
+your users and administrators.  If your site has a single home
 directory sharing between two or more clusters, you have a shared
 home file system.
 
diff --git a/docs/source/135_module_spider.rst b/docs/source/135_module_spider.rst
@@ -104,7 +104,7 @@ hdf5 module and not the phdf5 module.  It does report that other
 matches are possible (such as phdf5).  The reason for this is some
 sites name the  R stat package as R.  This rule is to prevent getting
 every module that has an 'r' in it.  Note that the searching for
-modules is case insensitve.  So *module spider openmpi* would match a
+modules is case insensitive.  So *module spider openmpi* would match a
 module named *OpenMPI*.
 
 If you search a name that only partially matches a module name then
diff --git a/docs/source/145_properties.rst b/docs/source/145_properties.rst
@@ -36,7 +36,7 @@ then Lmod searches for the property information in the following order:
 #. $LMOD_RC
 
 Where $LMOD_RC is an environment variable that can be set to point to
-any file locaiton. If there are more than one of these files exist
+any file location. If there are more than one of these files exist
 then they are merged and not a replacement.  So a site can (and
 should) leave the first file as is and create another one to specify
 site properties and Lmod will merge the information into one.
diff --git a/docs/source/260_sh_to_modulefile.rst b/docs/source/260_sh_to_modulefile.rst
@@ -65,7 +65,7 @@ Using **source_sh** ()
 ^^^^^^^^^^^^^^^^^^^^^^
 The feature of sourcing shell scripts inside a modulefile was
 introduced in Tmod 4.6+.  It has be shamelessly studied and
-re-implemented in Lmod 8.6+. In Lmod, this feature re-uses much of the
+re-implemented in Lmod 8.6+. In Lmod, this feature reuses much of the
 code that implements **sh_to_modulefile**.  This code does the
 following when performing a module load.
 
diff --git a/docs/source/300_tracking_module_usage.rst b/docs/source/300_tracking_module_usage.rst
@@ -252,7 +252,7 @@ d) Create the database by running the createDB.py program.::
 
       $ ./createDB.py
 
-   Note that createDB.py support --drop to remove the old databae.     
+   Note that createDB.py support --drop to remove the old database.     
 
 
 Step 7
diff --git a/docs/source/301_converting_to_gen2.rst b/docs/source/301_converting_to_gen2.rst
@@ -15,7 +15,7 @@ tracking database.  There are several reasons for this change:
    load.  It is now possible to block storing these modules.
 
 3. In studying our data, it became clear that many users were
-   loading the same modules repeatly during a day.  We have only
+   loading the same modules repeatedly during a day.  We have only
    been interested in distinct users use of modules.  Not how many
    times a user loaded a particular module.  So by default the
    `store_module_data` program only records the first use of a
diff --git a/docs/source/310_settarg.rst b/docs/source/310_settarg.rst
@@ -112,10 +112,10 @@ settarg changes your path to include $TARG by removing the old value
 of $TARG and replacing it with the new value of $TARG.  This way you
 can set $TARG, build, then run the new executable.
 
-Settarg integration witn prompt commands
+Settarg integration with prompt commands
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Tbe bash shell support an environment variable called "PROMPT_COMMAND".
+The bash shell support an environment variable called "PROMPT_COMMAND".
 If this variable is set to the name of a shell function, then for each
 new shell prompt, this command is run.  Similarly, zsh will run the
 "precmd" on every new prompt.  By default the settarg module defines a
diff --git a/docs/source/320_improving_perf.rst b/docs/source/320_improving_perf.rst
@@ -13,7 +13,7 @@ improve the loading of modules by doing the following steps:
 
 #. Configure Lmod to use LMOD_CACHED_LOADS=yes
 
-Theses are the most important steps.  As long as your site keeps the
+These are the most important steps.  As long as your site keeps the
 cache file up-to-day, the above steps will improve performance the
 most.
 
diff --git a/docs/source/340_inherit.rst b/docs/source/340_inherit.rst
@@ -7,12 +7,12 @@ A Personal Hierarchy Mirroring the System Hierarchy
 Suppose you as a user wants to have personal modules that work as part
 of the software hierarchy.  You might want to do that if you are a
 library or parallel application developer. You might want to test
-libraries or parallel applications before making them publically
+libraries or parallel applications before making them publicly
 available. These are two possible of many that you might want to
 mirror the software hierarchy. So how to go about it.
 
 The simplest to understand (but not implement) is to just copy over
-the entire compiler-mpi tree to your account and then tweek the
+the entire compiler-mpi tree to your account and then tweak the
 compiler and mpi modules to point inside your directory.  Once you
 have done that, you can add the modules that you need.
 
diff --git a/docs/source/410_Lmod_principals.rst b/docs/source/410_Lmod_principals.rst
@@ -137,7 +137,7 @@ A discussion on the design of Lmod:
   one structure called LocationT
 
 * Go to spec/*/*_spec.lua to see an example of what the structure looks
-  like.  For exmaple spec/DirTree/DirTree_spec.lua for what dirT looks
+  like.  For example spec/DirTree/DirTree_spec.lua for what dirT looks
   like and spec/ModuleA/ModuleA_spec.lua
 
 * When a module is loaded.  All is known is the userName. That is the
