Remove future tense from man pages

Remove all will, would, could, should and use present tense.

Signed-off-by: Daniel J Walsh <[email protected]>

Author: rhatdan

RELEASE_PROCESS.md

@@ -22,7 +22,7 @@ development efforts occur on the *main* branch.  Branches with a
   be dedicated to writing release notes.
 * For a **minor** or **patch** release, you have 2-4 hours of time available
   (minimum depends largely on the speed/reliability of automated testing)
-* You will annouce the release on the proper platforms
+* You will announce the release on the proper platforms
   (i.e. Podman blog, Twitter, Mastodon Podman and Podman-Desktop mailing lists)
 
 # Releases

docs/source/Introduction.rst

@@ -30,7 +30,7 @@ You can poke around in the busybox container for a while, but you’ll quickly f
 
 There’s an old saying that “nobody runs an operating system just to run an operating system” and the same is true with containers. It’s the workload running on top of an operating system or in a container that’s interesting and valuable.
 
-Sometimes we can find a publicly available container image for the exact workload we’re looking for and it will already be packaged exactly how we want. But, more often than not, there’s something that we want to add, remove, or customize. It could be as simple as a configuration setting for security or performance, or as complex as adding a complex workload. Either way, containers make it fairly easy to make the changes we need.
+Sometimes we can find a publicly available container image for the exact workload we’re looking for and it will already be packaged exactly how we want. But, more often than not, there’s something that we want to add, remove, or customize. It can be as simple as a configuration setting for security or performance, or as complex as adding a complex workload. Either way, containers make it fairly easy to make the changes we need.
 
 Container Images aren’t actually images, they’re repositories often made up of multiple layers. These layers can easily be added, saved, and shared with others by using a Containerfile (Dockerfile). This single file often contains all the instructions needed to build a new container image and can easily be shared with others publicly using tools like GitHub.
 
@@ -49,7 +49,7 @@ Output::
     <p><em>Thank you for using nginx.</em></p>
     ...
 
-Building new images is great, but sharing our work with others let’s them review our work, critique how we built them, and offer improved versions. Our newly built Nginx image could be published at quay.io or docker.io to share it with the world. Everything needed to run the Nginx application is provided in the container image. Others could easily pull it down and use it, or make improvements to it.
+Building new images is great, but sharing our work with others lets them review our work, critique how we built them, and offer improved versions. Our newly built Nginx image can be published at quay.io or docker.io to share it with the world. Everything needed to run the Nginx application is provided in the container image. Others can easily pull it down and use it, or make improvements to it.
 
 Standardizing on container images and `Container Registries`_ enable a new level of collaboration through simple consumption. This simple consumption model is possible because every major Container Engine and Registry Server uses the Open Containers Initiative (OCI_) format. This allows users to find, run, build, share and deploy containers anywhere they want. Podman and other `Container Engines`_ like CRI-O, Docker, or containerd can create and consume container images from docker.io, quay.io, an on premise registry or even one provided by a cloud provider. The OCI image format facilitates this ecosystem through a single standard.
 

docs/source/markdown/options/README.md

@@ -16,12 +16,12 @@ The files here are included in `podman-*.md.in` files using the `@@option`
 mechanism:
 
 ```
-@@option foo           ! will include options/foo.md
+@@option foo           ! includes options/foo.md
 ```
 
 The tool that does this is `hack/markdown-preprocess`. It is a python
 script because it needs to run on `readthedocs.io`. From a given `.md.in`
-file, this script will create a `.md` file that can then be read by
+file, this script creates a `.md` file that can then be read by
 `go-md2man`, `sphinx`, anything that groks markdown. This runs as
 part of `make docs`.
 
@@ -32,11 +32,11 @@ Some options are almost identical except for 'pod' vs 'container'
 differences. For those, use `<<text for pods|text for containers>>`.
 Order is immaterial: the important thing is the presence of the
 string "`pod`" in one half but not the other. The correct string
-will be chosen based on the filename: if the file contains `-pod`,
+is chosen based on the filename: if the file contains `-pod`,
 such as `podman-pod-create`, the string with `pod` (case-insensitive)
-in it will be chosen.
+in it is chosen.
 
-The string `<<subcommand>>` will be replaced with the podman subcommand
+The string `<<subcommand>>` is replaced with the podman subcommand
 as determined from the filename, e.g., `create` for `podman-create.1.md.in`.
 This allows the shared use of examples in the option file:
 ```
@@ -54,7 +54,7 @@ back-ticks in the front and the end of the line.  For instance:
 
 \`\`\`Some man page text\`\`\`
 
-This is currently not allowed and will cause a corruption of the
+This is currently not allowed and causes a corruption of the
 compiled man page.  Instead, put the three back-ticks on separate
 lines like:
 

docs/source/markdown/options/arch.md

@@ -4,4 +4,4 @@
 ####> are applicable to all of those.
 #### **--arch**=*ARCH*
 Override the architecture, defaults to hosts, of the image to be pulled. For example, `arm`.
-Unless overridden, subsequent lookups of the same image in the local storage will match this architecture, regardless of the host.
+Unless overridden, subsequent lookups of the same image in the local storage matches this architecture, regardless of the host.

docs/source/markdown/options/cgroup-parent.md

@@ -4,6 +4,6 @@
 ####> are applicable to all of those.
 #### **--cgroup-parent**=*path*
 
-Path to cgroups under which the cgroup for the <<container|pod>> will be created. If the
+Path to cgroups under which the cgroup for the <<container|pod>> is created. If the
 path is not absolute, the path is considered to be relative to the cgroups path
-of the init process. Cgroups will be created if they do not already exist.
+of the init process. Cgroups are created if they do not already exist.

docs/source/markdown/options/cgroups.md

@@ -4,11 +4,11 @@
 ####> are applicable to all of those.
 #### **--cgroups**=*how*
 
-Determines whether the container will create CGroups.
+Determines whether the container creates CGroups.
 
 Default is **enabled**.
 
-The **enabled** option will create a new cgroup under the cgroup-parent.
-The **disabled** option will force the container to not create CGroups, and thus conflicts with CGroup options (**--cgroupns** and **--cgroup-parent**).
+The **enabled** option creates a new cgroup under the cgroup-parent.
+The **disabled** option forces the container to not create CGroups, and thus conflicts with CGroup options (**--cgroupns** and **--cgroup-parent**).
 The **no-conmon** option disables a new CGroup only for the **conmon** process.
 The **split** option splits the current CGroup in two sub-cgroups: one for conmon and one for the container payload. It is not possible to set **--cgroup-parent** with **split**.

docs/source/markdown/options/chrootdirs.md

@@ -4,6 +4,6 @@
 ####> are applicable to all of those.
 #### **--chrootdirs**=*path*
 
-Path to a directory inside the container that should be treated as a `chroot` directory.
-Any Podman managed file (e.g., /etc/resolv.conf, /etc/hosts, etc/hostname) that is mounted into the root directory will be mounted into that location as well.
-Multiple directories should be separated with a comma.
+Path to a directory inside the container that is treated as a `chroot` directory.
+Any Podman managed file (e.g., /etc/resolv.conf, /etc/hosts, etc/hostname) that is mounted into the root directory is mounted into that location as well.
+Multiple directories are separated with a comma.

docs/source/markdown/options/cidfile.write.md

@@ -4,4 +4,4 @@
 ####> are applicable to all of those.
 #### **--cidfile**=*file*
 
-Write the container ID to *file*.  The file will be removed along with the container.
+Write the container ID to *file*.  The file is removed along with the container.

docs/source/markdown/options/cpu-period.md

@@ -5,8 +5,8 @@
 #### **--cpu-period**=*limit*
 
 Set the CPU period for the Completely Fair Scheduler (CFS), which is a
-duration in microseconds. Once the container's CPU quota is used up, it will
-not be scheduled to run until the current period ends. Defaults to 100000
+duration in microseconds. Once the container's CPU quota is used up, it will not
+be scheduled to run until the current period ends. Defaults to 100000
 microseconds.
 
 On some systems, changing the resource limits may not be allowed for non-root

docs/source/markdown/options/cpu-quota.md

@@ -8,7 +8,7 @@ Limit the CPU Completely Fair Scheduler (CFS) quota.
 
 Limit the container's CPU usage. By default, containers run with the full
 CPU resource. The limit is a number in microseconds. If a number is provided,
-the container will be allowed to use that much CPU time until the CPU period
+the container is allowed to use that much CPU time until the CPU period
 ends (controllable via **--cpu-period**).
 
 On some systems, changing the resource limits may not be allowed for non-root

docs/source/markdown/options/cpu-rt-runtime.md

@@ -7,7 +7,7 @@
 Limit the CPU real-time runtime in microseconds.
 
 Limit the containers Real Time CPU usage. This option tells the kernel to limit the amount of time in a given CPU period Real Time tasks may consume. Ex:
-Period of 1,000,000us and Runtime of 950,000us means that this container could consume 95% of available CPU and leave the remaining 5% to normal priority tasks.
+Period of 1,000,000us and Runtime of 950,000us means that this container can consume 95% of available CPU and leave the remaining 5% to normal priority tasks.
 
 The sum of all runtimes across containers cannot exceed the amount allotted to the parent cgroup.
 

docs/source/markdown/options/cpu-shares.md

@@ -11,14 +11,14 @@ proportion can be modified by changing the container's CPU share weighting
 relative to the combined weight of all the running containers.
 Default weight is **1024**.
 
-The proportion will only apply when CPU-intensive processes are running.
+The proportion only applies when CPU-intensive processes are running.
 When tasks in one container are idle, other containers can use the
-left-over CPU time. The actual amount of CPU time will vary depending on
+left-over CPU time. The actual amount of CPU time varies depending on
 the number of containers running on the system.
 
 For example, consider three containers, one has a cpu-share of 1024 and
 two others have a cpu-share setting of 512. When processes in all three
-containers attempt to use 100% of CPU, the first container would receive
+containers attempt to use 100% of CPU, the first container receives
 50% of the total CPU time. If a fourth container is added with a cpu-share
 of 1024, the first container only gets 33% of the CPU. The remaining containers
 receive 16.5%, 16.5% and 33% of the CPU.

docs/source/markdown/options/cpuset-mems.md

@@ -8,7 +8,7 @@ Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on
 NUMA systems.
 
 If there are four memory nodes on the system (0-3), use **--cpuset-mems=0,1**
-then processes in the container will only use memory from the first
+then processes in the container only uses memory from the first
 two memory nodes.
 
 On some systems, changing the resource limits may not be allowed for non-root

docs/source/markdown/options/creds.md

@@ -5,7 +5,7 @@
 #### **--creds**=*[username[:password]]*
 
 The [username[:password]] to use to authenticate with the registry, if required.
-If one or both values are not supplied, a command line prompt will appear and the
+If one or both values are not supplied, a command line prompt appears and the
 value can be entered. The password is entered without echo.
 
 Note that the specified credentials are only used to authenticate against

docs/source/markdown/options/decryption-key.md

@@ -4,4 +4,4 @@
 ####> are applicable to all of those.
 #### **--decryption-key**=*key[:passphrase]*
 
-The [key[:passphrase]] to be used for decryption of images. Key can point to keys and/or certificates. Decryption will be tried with all keys. If the key is protected by a passphrase, it is required to be passed in the argument and omitted otherwise.
+The [key[:passphrase]] to be used for decryption of images. Key can point to keys and/or certificates. Decryption is tried with all keys. If the key is protected by a passphrase, it is required to be passed in the argument and omitted otherwise.

docs/source/markdown/options/detach-keys.md

@@ -4,6 +4,6 @@
 ####> are applicable to all of those.
 #### **--detach-keys**=*sequence*
 
-Specify the key sequence for detaching a container. Format is a single character `[a-Z]` or one or more `ctrl-<value>` characters where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`. Specifying "" will disable this feature. The default is *ctrl-p,ctrl-q*.
+Specify the key sequence for detaching a container. Format is a single character `[a-Z]` or one or more `ctrl-<value>` characters where `<value>` is one of: `a-z`, `@`, `^`, `[`, `,` or `_`. Specifying "" disables this feature. The default is *ctrl-p,ctrl-q*.
 
 This option can also be set in **containers.conf**(5) file.

docs/source/markdown/options/device.md

@@ -10,11 +10,11 @@ can be used to specify device permissions by combining
 
 Example: **--device=/dev/sdc:/dev/xvdc:rwm**.
 
-Note: if *host-device* is a symbolic link then it will be resolved first.
-The <<container|pod>> will only store the major and minor numbers of the host device.
+Note: if *host-device* is a symbolic link then it is resolved first.
+The <<container|pod>> only stores the major and minor numbers of the host device.
 
 Podman may load kernel modules required for using the specified
-device. The devices that Podman will load modules for when necessary are:
+device. The devices that Podman loads modules for when necessary are:
 /dev/fuse.
 
 In rootless mode, the new device is bind mounted in the container from the host

docs/source/markdown/options/dns.md

@@ -12,4 +12,4 @@ host DNS configuration is invalid for the container (e.g., **127.0.0.1**). When
 is the case the **--dns** flag is necessary for every run.
 
 The special value **none** can be specified to disable creation of _/etc/resolv.conf_ in the container by Podman.
-The _/etc/resolv.conf_ file in the image will be used without changes.
+The _/etc/resolv.conf_ file in the image is used without changes.

docs/source/markdown/options/env-merge.md

@@ -6,4 +6,4 @@
 
 Preprocess default environment variables for the containers. For example
 if image contains environment variable `hello=world` user can preprocess
-it using `--env-merge hello=${hello}-some` so new value will be `hello=world-some`.
+it using `--env-merge hello=${hello}-some` so new value is `hello=world-some`.

docs/source/markdown/options/env.md

@@ -6,4 +6,4 @@
 
 Set environment variables.
 
-This option allows arbitrary environment variables that are available for the process to be launched inside of the container. If an environment variable is specified without a value, Podman will check the host environment for a value and set the variable only if it is set on the host. As a special case, if an environment variable ending in __*__ is specified without a value, Podman will search the host environment for variables starting with the prefix and will add those variables to the container.
+This option allows arbitrary environment variables that are available for the process to be launched inside of the container. If an environment variable is specified without a value, Podman checks the host environment for a value and set the variable only if it is set on the host. As a special case, if an environment variable ending in __*__ is specified without a value, Podman searches the host environment for variables starting with the prefix and adds those variables to the container.

docs/source/markdown/options/follow.md

@@ -8,4 +8,4 @@ Follow log output.  Default is false.
 
 Note: When following a <<container|pod>> which is removed by `podman <<container|pod>> rm`
 or removed on exit (`podman run --rm ...`), there is a chance that the log
-file will be removed before `podman<< pod|>> logs` reads the final content.
+file is removed before `podman<< pod|>> logs` reads the final content.

docs/source/markdown/options/gidmap.pod.md

@@ -4,5 +4,5 @@
 ####> are applicable to all of those.
 #### **--gidmap**=*pod_gid:host_gid:amount*
 
-GID map for the user namespace. Using this flag will run all containers in the pod with user namespace enabled.
+GID map for the user namespace. Using this flag runs all containers in the pod with user namespace enabled.
 It conflicts with the **--userns** and **--subgidname** flags.

docs/source/markdown/options/health-cmd.md

@@ -8,5 +8,5 @@ Set or alter a healthcheck command for a container. The command is a command to
 container that determines the container health. The command is required for other healthcheck options
 to be applied. A value of **none** disables existing healthchecks.
 
-Multiple options can be passed in the form of a JSON array; otherwise, the command will be interpreted
+Multiple options can be passed in the form of a JSON array; otherwise, the command is interpreted
 as an argument to **/bin/sh -c**.

docs/source/markdown/options/health-startup-cmd.md

@@ -4,8 +4,8 @@
 ####> are applicable to all of those.
 #### **--health-startup-cmd**=*"command"* | *'["command", "arg1", ...]'*
 
-Set a startup healthcheck command for a container. This command will be executed inside the container and is used to gate the regular
-healthcheck. When the startup command succeeds, the regular healthcheck will begin and the startup healthcheck will cease. Optionally,
-if the command fails for a set number of attempts, the container will be restarted. A startup healthcheck can be used to ensure that
+Set a startup healthcheck command for a container. This command is executed inside the container and is used to gate the regular
+healthcheck. When the startup command succeeds, the regular healthcheck begins and the startup healthcheck ceases. Optionally,
+if the command fails for a set number of attempts, the container is restarted. A startup healthcheck can be used to ensure that
 containers with an extended startup period are not marked as unhealthy until they are fully started. Startup healthchecks can only be
 used when a regular healthcheck (from the container's image or the **--health-cmd** option) is also set.

docs/source/markdown/options/health-startup-retries.md

@@ -4,5 +4,4 @@
 ####> are applicable to all of those.
 #### **--health-startup-retries**=*retries*
 
-The number of attempts allowed before the startup healthcheck restarts the container. If set to **0**, the container will never be
-restarted. The default is **0**.
+The number of attempts allowed before the startup healthcheck restarts the container. If set to **0**, the container is never restarted. The default is **0**.

docs/source/markdown/options/health-startup-success.md

@@ -4,5 +4,5 @@
 ####> are applicable to all of those.
 #### **--health-startup-success**=*retries*
 
-The number of successful runs required before the startup healthcheck will succeed and the regular healthcheck will begin. A value
-of **0** means that any success will begin the regular healthcheck. The default is **0**.
+The number of successful runs required before the startup healthcheck succeeds and the regular healthcheck begins. A value
+of **0** means that any success begins the regular healthcheck. The default is **0**.

docs/source/markdown/options/hostname.container.md

@@ -6,4 +6,4 @@
 
 Container host name
 
-Sets the container host name that is available inside the container. Can only be used with a private UTS namespace `--uts=private` (default). If `--pod` is specified and the pod shares the UTS namespace (default) the pod's hostname will be used.
+Sets the container host name that is available inside the container. Can only be used with a private UTS namespace `--uts=private` (default). If `--pod` is specified and the pod shares the UTS namespace (default) the pod's hostname is used.