Typos found by codespell

README.md

@@ -31,7 +31,7 @@ pip3 install --user Sphinx sphinx-rtd-theme
 
 If your version of python 3 does not come with `pip` / `pip3`, you may need to
 install a `python3-pip`package with `apt` or `yum`, or you can install pip
-follwing [the instructions here](https://pip.pypa.io/en/stable/installing/).
+following [the instructions here](https://pip.pypa.io/en/stable/installing/).
 
 You're all set! After this you will only need to use your favorite editor to
 work with the RST files.

bind_paths_and_mounts.rst

@@ -136,7 +136,7 @@ within the container.  {Singularity} can often carry out this operation even in
 the absence of the "overlay fs" feature.
 
 However, binding paths to non-existent points within the container can result in
-unexpected behavior when used in conjuction with the ``--writable`` flag, and is
+unexpected behavior when used in conjunction with the ``--writable`` flag, and is
 therefore disallowed. If you need to specify bind paths in combination with the
 ``--writable`` flag, please ensure that the appropriate bind points exist within
 the container. If they do not already exist, it will be necessary to modify the

build_env.rst

@@ -55,7 +55,7 @@ a location that is:
 .. warning::
 
    If you are not certain that your ``$HOME`` or
-   ``SINGULARITY_CACHEDIR`` filesytems support atomic rename, do not
+   ``SINGULARITY_CACHEDIR`` filesystems support atomic rename, do not
    run {Singularity} in parallel using remote container URLs. Instead
    use ``singularity pull`` to create a local SIF image, and then run
    this SIF image in a parallel step. An alternative is to use the
@@ -316,4 +316,3 @@ Encryption
 **SINGULARITY_ENCRYPTION_PASSPHRASE** Used to pass a plaintext passphrase to encrypt a container file system (with the ``--encrypt`` flag). The default is empty.
 
 **SINGULARITY_ENCRYPTION_PEM_PATH** Used to specify the location of a public key to use for container encryption (with the ``--encrypt`` flag). The default is empty.
-

cli.rst

@@ -11,4 +11,3 @@ Below are links to the automatically generated CLI docs
    :glob:
 
    cli/*
-

cloud_library.rst

@@ -68,7 +68,7 @@ The ``:latest`` is the container tag. Tags are used to have different
 version of the same container.
 
 .. note::
-    When pushing your container, theres no need to add a ``.sif`` (Singularity Image Format) to the end of the container name, (like
+    When pushing your container, there's no need to add a ``.sif`` (Singularity Image Format) to the end of the container name, (like
     on your local machine), because all containers on the library are SIF containers.
 
 Let's assume you have your container (v1.0.1), and you want to push
@@ -307,4 +307,3 @@ After building, you can test your container like so:
 You can also use the web GUI to build containers remotely. First, go to https://cloud.sylabs.io/builder (make sure you are signed in).
 Then you can copy and paste, upload, or type your definition file. When you are finished, click build. Then you can download the container
 with the URL.
-

contributing.rst

@@ -203,9 +203,3 @@ will need to follow the next steps:
         git push origin master && # to update your fork \
         git checkout new-feature && \
         git merge master 
-
-
-
-
-
-

definition_files.rst

@@ -692,7 +692,7 @@ collection of different containers.
 {Singularity} implements SCIF, and you can read more about how to use it
 below.
 
-SCIF is not specfic to {Singularity}. You can learn more about it at the
+SCIF is not specific to {Singularity}. You can learn more about it at the
 project's site: `<https://sci-f.github.io/>`_ which includes extended
 tutorials, the specification, and other information.
 

encryption.rst

@@ -126,7 +126,7 @@ like so:
 
 .. code-block:: none
 
-        # Generate a keypair
+        # Generate a key pair
         $ ssh-keygen -t rsa -b 2048
         Generating public/private rsa key pair.
         Enter file in which to save the key (/home/vagrant/.ssh/id_rsa): rsa
@@ -220,4 +220,4 @@ Running using an environment variable
 
 .. code-block:: none
 
-        $ SINGULARITY_ENCRYPTION_PEM_PATH=rsa_pri.pem singularity run encrypted.sif
+        $ SINGULARITY_ENCRYPTION_PEM_PATH=rsa_pri.pem singularity run encrypted.sif

environment_and_metadata.rst

@@ -291,7 +291,7 @@ Manipulating ``PATH``
 
 ``PATH`` is a special environment variable that tells a system where
 to look for programs that can be run. ``PATH`` contains multiple
-filesytem locations (paths) separated by colons. When you ask to run a
+filesystem locations (paths) separated by colons. When you ask to run a
 program ``myprog``, the system looks through these locations one by
 one, until it finds ``myprog``.
 
@@ -758,7 +758,7 @@ the SIF file metadata descriptor.
    runtime, *and should not be modified* in the container.
 
 -  **env**: All ``*.sh`` files in this directory are sourced in
-   alpha-numeric order when the container is started. For legacy
+   alphanumeric order when the container is started. For legacy
    purposes there is a symbolic link called ``/environment`` that
    points to ``/.singularity.d/env/90-environment.sh``. Whenever
    possible, avoid modifying or creating environment files manually to

gpu.rst

@@ -46,7 +46,7 @@ ensure that:
 * The application inside your container was compiled for a CUDA version, and
   device capability level, that is supported by the host card and driver.
 
-These requirements are usually satisified by installing the NVIDIA drivers and
+These requirements are usually satisfied by installing the NVIDIA drivers and
 CUDA packages directly from the NVIDIA website. Linux distributions may provide
 NVIDIA drivers and CUDA libraries, but they are often outdated which can lead to
 problems running applications compiled for the latest versions of CUDA.

introduction.rst

@@ -154,4 +154,3 @@ Consolidating a work-flow into a {Singularity} container simplifies
 distribution and replication of scientific results. Making containers
 available along with published work enables other scientists to build
 upon (and verify) previous scientific work.
-

license.rst

@@ -6,4 +6,3 @@ This documentation is subject to the following 3-clause BSD license:
 
 .. include:: LICENSE
    :literal:
-

networking.rst

@@ -118,7 +118,7 @@ to the ``network`` configuration directory as required, and
 ==================
 
 The ``--network-args`` option provides a convenient way to specify arguments to
-pass directly to the cni plugins.  It must be used in conjuction with the
+pass directly to the cni plugins.  It must be used in conjunction with the
 ``--net`` flag.
 
 For instance, let's say you want to start an `NGINX <https://www.nginx.com/>`_

oci_runtime.rst

@@ -62,7 +62,7 @@ Suppose the Singularity Image Format (SIF) file ``busybox_latest.sif`` exists lo
 
 This is one way to bootstrap creation of this image in SIF that *retains* a local copy - i.e., a local copy of the SIF file *and* a cached copy of the OCI blobs. Additional approaches and details can be found in the section :ref:`Support for Docker and OCI <singularity-and-docker>`). 
 
-For the purpose of boostrapping the creation of an OCI compliant container, this SIF file can be mounted as follows: 
+For the purpose of bootstrapping the creation of an OCI compliant container, this SIF file can be mounted as follows: 
 
 .. code-block:: none 
 

pygments_json.py

@@ -63,7 +63,7 @@ class JSONLexer(RegexLexer):
         ],
 
 
-        # the root of a json document whould be a value
+        # the root of a json document would be a value
         'root': [
             include('value'),
         ],

pygments_singularity.py

@@ -31,4 +31,3 @@ class SingularityLexer(RegexLexer):
             (r'(.+?(?=^\s*%))|(.*)', using(BashLexer), '#pop'),
         ],
     }
-

running_services.rst

@@ -425,7 +425,7 @@ Filesystem (SCIF) apps.
    {Singularity} implements SCIF, and you can read more about how to use it
    :ref:`apps <in the SCIF Apps section>`.
 
-   SCIF is not specfic to {Singularity}. You can learn more about it at the
+   SCIF is not specific to {Singularity}. You can learn more about it at the
    project site: <https://sci-f.github.io/>`_.
 
 
@@ -576,7 +576,7 @@ or another supervisor daemon installed on your host. Many init and supervisor
 daemons support managing processes via pid files.
 
 You can specify a `--pid-file` option to `singularity instance start` to write
-the PID for an instance to the specifed file, e.g.
+the PID for an instance to the specified file, e.g.
 
 .. code-block:: none
 

security.rst

@@ -43,7 +43,7 @@ SingularityPRO - Long Term Support & Security Patches
 
 Security patches for {Singularity} are applied to the latest open-source
 version, so it is important to follow new releases and upgrade when
-neccessary.
+necessary.
 
 SingularityPRO is a professionally curated and licensed version of
 {Singularity} that provides added security, stability, and support
@@ -72,7 +72,7 @@ privileges once they are inside of a container. The container file
 system is mounted using the ``nosuid`` option, and processes are
 started with the ``PR_NO_NEW_PRIVS`` flag set. This means that even if
 you run `sudo` inside your container, you won't be able to change to
-another user, or gain root priveleges by other means. This approach
+another user, or gain root privileges by other means. This approach
 provides a secure way for users to run containers and greatly
 simplifies things like reading and writing data to the host system
 with appropriate ownership.
@@ -95,7 +95,7 @@ Singularity Image Format (SIF)
 ##############################
 
 Ensuring container security as a continuous process. {Singularity}
-provides ways to ensure integrity throughout the lifecyle of a
+provides ways to ensure integrity throughout the lifecycle of a
 container, i.e. at rest, in transit and while running. The SIF
 Singularity Image Format has been designed to achieve these goals.
 
@@ -171,7 +171,7 @@ Security in the Sylabs Cloud
 ############################
 
 `Sylabs Cloud <https://cloud.sylabs.io/home>`_ consists of a Remote
-Builder, a Container Library, and a Keystore. Together, theses
+Builder, a Container Library, and a Keystore. Together, these
 services provide an end-to-end solution for packaging and distributing
 applications in secure and trusted containers.
 
@@ -244,6 +244,3 @@ Authentication and encryption
    request between the services is authenticated using the
    authentication token supplied by the user in the associated
    request.
-
-
-

signNverify.rst

@@ -342,4 +342,3 @@ container is signed, and the default ``verify`` behavior without specifying
     2   |1       |NONE    |JSON.Generic
     3   |1       |NONE    |FS
     Container verified: my_container.sif
-

singularity_and_docker.rst

@@ -232,7 +232,7 @@ complete contents of that image.
 
     ``pull`` is a one-time-only operation that builds a SIF file corresponding to the image retrieved from Docker Hub. Updates to the image on Docker Hub will *not* be reflected in the *local* copy.
 
-In our example ``docker://sylabsio/lolcow``, ``sylabsio`` specifies a Docker Hub user, whereas ``lolcow`` is the name of the repository. Adding the option to specifiy an image tag, the generic version of the URI is ``docker://<user>/<repo-name>[:<tag>]``. `Repositories on Docker Hub <https://docs.docker.com/docker-hub/repos/>`_ provides additional details.
+In our example ``docker://sylabsio/lolcow``, ``sylabsio`` specifies a Docker Hub user, whereas ``lolcow`` is the name of the repository. Adding the option to specify an image tag, the generic version of the URI is ``docker://<user>/<repo-name>[:<tag>]``. `Repositories on Docker Hub <https://docs.docker.com/docker-hub/repos/>`_ provides additional details.
 
 
 .. _sec:using_prebuilt_private_images:
@@ -316,7 +316,7 @@ Based upon these exports, ``$ singularity pull docker://sylabsio/private`` allow
 
 .. note::
 
-    This approach for authentication supports both interactive and non-interactive sessions. However, the requirement for a plain-text password assigned to an envrionment variable, is the security compromise for this flexibility.
+    This approach for authentication supports both interactive and non-interactive sessions. However, the requirement for a plain-text password assigned to an environment variable, is the security compromise for this flexibility.
 
 .. note::
 
@@ -402,7 +402,7 @@ Alternatively, for purely interactive use, ``--docker-login`` is recommended:
     INFO:    Creating SIF file...
     INFO:    Build complete: pytorch_18.11-py3.sif
 
-Authentication aside, the outcome of the ``pull`` command is the {Singularity} container ``pytorch_18.11-py3.sif`` - i.e., a locally stored copy, that has been coverted to SIF.
+Authentication aside, the outcome of the ``pull`` command is the {Singularity} container ``pytorch_18.11-py3.sif`` - i.e., a locally stored copy, that has been converted to SIF.
 
 
 --------------------------------------------------------
@@ -746,7 +746,7 @@ enables authenticated use of the private image.
 
 .. note::
 
-    The ``-E`` option is required to preserve the user's existing environment variables upon ``sudo`` invocation - a priviledge escalation *required* to create {Singularity} containers via the ``build`` command.
+    The ``-E`` option is required to preserve the user's existing environment variables upon ``sudo`` invocation - a privilege escalation *required* to create {Singularity} containers via the ``build`` command.
 
 
 Remotely Bootstrapped and Built Containers
@@ -802,7 +802,7 @@ A copy of the SIF file created by the service remains in the Sylabs Cloud {Singu
 
 .. note::
 
-    The Sylabs Cloud is currently available as an Alpha Preview. In addition to the {Singularity} Library and Remote Builder, a Keystore service is also available. All three services make use of a *freemium* pricing model in supporting {Singularity} Community Edition. In contrast, all three services are included in SingularityPRO - an enterprise grade subscription for {Singularity} that is offered for a fee from Sylabs. For addtional details regarding the different offerings available for {Singularity}, please `consult the Sylabs website <https://www.sylabs.io/singularity/>`_.
+    The Sylabs Cloud is currently available as an Alpha Preview. In addition to the {Singularity} Library and Remote Builder, a Keystore service is also available. All three services make use of a *freemium* pricing model in supporting {Singularity} Community Edition. In contrast, all three services are included in SingularityPRO - an enterprise grade subscription for {Singularity} that is offered for a fee from Sylabs. For additional details regarding the different offerings available for {Singularity}, please `consult the Sylabs website <https://www.sylabs.io/singularity/>`_.
 
 
 .. _sec:mandatory_headers_docker_locally_bootstrapped_def_file:
@@ -995,7 +995,7 @@ Suppose now that a {Singularity} ``%runscript`` **section** is added to the defi
 
         date
 
-After conversion to SIF via the {Singularity} ``build`` command, exection of the resulting container produces the output:
+After conversion to SIF via the {Singularity} ``build`` command, execution of the resulting container produces the output:
 
 .. code-block:: none
 
@@ -1450,7 +1450,7 @@ The syntax for the ``oci`` bootstrap agent requires some elaboration, however. I
     blobs  index.json  oci-layout
 
 
-In other words, it is the ``$OCI_BUNDLE_DIR`` containing the data and metadata that collectively comprise the image layed out in accordance with the OCI Image Layout Specification :ref:`as discussed previously <misc:OCI_Image_Layout_Specification>` - the same data and metadata that are assembled into a single SIF file through the ``build`` process. However,
+In other words, it is the ``$OCI_BUNDLE_DIR`` containing the data and metadata that collectively comprise the image laid out in accordance with the OCI Image Layout Specification :ref:`as discussed previously <misc:OCI_Image_Layout_Specification>` - the same data and metadata that are assembled into a single SIF file through the ``build`` process. However,
 
 .. code-block:: none
 
@@ -1536,7 +1536,7 @@ In the previous section, an OCI archive was created from locally available OCI b
 
 Thus ``https`` (and ``http``) are additional bootstrap agents available to seed development of containers for {Singularity}.
 
-It is worth noting that the OCI image specfication compliant contents of this archive are:
+It is worth noting that the OCI image specification compliant contents of this archive are:
 
 .. code-block:: none
 
@@ -1668,8 +1668,8 @@ Applying ``build`` as follows
 results in the SIF container ``lolcow_oci_tarfile.sif``.
 
 
-Working with Definition Files: Additonal Considerations
--------------------------------------------------------
+Working with Definition Files: Additional Considerations
+--------------------------------------------------------
 
 In working with definition files, the following additional considerations arise:
 
@@ -1737,7 +1737,7 @@ Best Practices
 
     Docker containers *allow for* privilege escalation. In a ``Dockerfile``, for example, the ``USER`` instruction allows for user and/or group settings to be made in the Linux operating environment. The trust model in {Singularity} is completely different: {Singularity} allows untrusted users to run untrusted containers in a trusted way. Because {Singularity} containers embodied as SIF files execute in *user* space, there is no possibility for privilege escalation. In other words, those familiar with Docker, should *not* expect access to elevated user permissions; and as a corollary, use of the ``USER`` instruction must be *avoided*.
 
-    {Singularity} does, however, allow for fine-grained control over the permissions that containers require for execution. Given that Singularilty executes in user space, it is not surprising that permissions need to be externally established *for* the container through use of the ``capability`` command. :ref:`Detailed elsewhere in this documentation <security-options>`, {Singularity} allows users and/or groups to be granted/revoked authorized capabilties. Owing to {Singularity}'s trust model, this fundamental best practice can be stated as follows:
+    {Singularity} does, however, allow for fine-grained control over the permissions that containers require for execution. Given that Singularilty executes in user space, it is not surprising that permissions need to be externally established *for* the container through use of the ``capability`` command. :ref:`Detailed elsewhere in this documentation <security-options>`, {Singularity} allows users and/or groups to be granted/revoked authorized capabilities. Owing to {Singularity}'s trust model, this fundamental best practice can be stated as follows:
 
         "Employ ``singularity capability`` to manage execution privileges for containers"
 
@@ -1785,7 +1785,7 @@ Best Practices
 
     8. Use of plain-text passwords for authentication
 
-    For obvious reasons, it is desireable to completely *avoid* use of plain-text passwords. Therefore, for interactive sessions requiring authentication, use of the ``--docker-login`` option for {Singularity}'s ``pull`` and ``build`` commands is *recommended*. At the present time, the *only* option available for non-interactive use is to :ref:`embed plain-text passwords into environment variables <sec:authentication_via_environment_variables>`. Because the Sylabs Cloud {Singularity} Library employs `time-limited API tokens for authentication <https://cloud.sylabs.io/auth>`_, use of SIF containers hosted through this service provides a more secure means for both interactive *and* non-interactive use. This best practice is:
+    For obvious reasons, it is desirable to completely *avoid* use of plain-text passwords. Therefore, for interactive sessions requiring authentication, use of the ``--docker-login`` option for {Singularity}'s ``pull`` and ``build`` commands is *recommended*. At the present time, the *only* option available for non-interactive use is to :ref:`embed plain-text passwords into environment variables <sec:authentication_via_environment_variables>`. Because the Sylabs Cloud {Singularity} Library employs `time-limited API tokens for authentication <https://cloud.sylabs.io/auth>`_, use of SIF containers hosted through this service provides a more secure means for both interactive *and* non-interactive use. This best practice is:
 
         "Avoid use of plain-text passwords"