First pass terminology reviews: (#1144)

* Each document was reviewed for inclusive, gender neutral, and other "possible" offensive terms using vale and the alex, Red Hat and vale built in dictionaries.
* there is more to do in each of these documents but they have been improved.

Author: sspencerwire

docs/guides/automation/anacron.md

@@ -9,18 +9,18 @@ update : 2021-10-20
 
 ##  Prerequisites
 
-* A machine running Rocky Linux.
-* Know how to use your favorite editor to modify the configuration file (such as *vim*) in the command line environment.
+* A computer running Rocky Linux.
+* Know how to use your favorite editor to change the configuration file (such as *vim*) in the command line environment.
 * Understand basic RPM package management.
 
 ##  Assumptions
 
-* You have understood the basic knowledge of bash, python or other scripting/programming tools, and want to run the script automatically.
-* You are logged in as the root user, or switch to root with `su - root`.
+* You have understood the basic knowledge of bash, python or other scripting or programming tools, and want to run the script automatically.
+* You connected in as the root user, or switch to root with `su - root`.
 
 ##  `anacron` Introduction
 
-**`anacron` is used to run commands on a regular basis, and the operating frequency is defined in units of days. It is suitable for computers that do not run 24/7, such as laptops and desktops. Suppose you have a scheduled task (such as a backup script) to be run in the early morning of every day using crontab. When you fall asleep, your desktop/laptop is shut down. Your backup script will not be executed. However, if you use `anacron`, you can rest assured that the next time you turn on the desktop/laptop, the backup script will be executed.**
+**`anacron` runs commands on a regular basis, and the operating frequency is defined in units of days. It is suitable for computers that do not run 24/7, such as laptops and desktops. Suppose you have a scheduled task (such as a backup script) to be run in the early morning of every day using crontab. When you fall asleep, your desktop or notebook is off. Your backup script will not run. However, if you use `anacron`, you can rest assured that the next time you turn on the desktop or notebook, the backup script will run.**
 
 The appearance of `anacron` is not to replace `crontab`, but to complement `crontab`. Their relationship is as follows:
 
@@ -93,24 +93,24 @@ For more configuration file information, please [Browse the manual page](https:/
 
 ## User use
 
-In order to make certain files run within these automatically defined times, all you need to do is to copy the script file to the relevant directory and make sure that it has ** x execution permission (chmod +x) ** . Therefore, you only need to let the system automatically run the script at one of these scheduled times, which makes the automation task very easy.
+To make certain files run within these automatically defined times, all you need to do is to copy the script file to the relevant directory and verify that it has ** x execution permission (chmod +x) ** . Therefore, you only need to let the system automatically run the script at one of these scheduled times, which simplifies the automation task.
 
-Let's use cron.daily to illustrate the execution process of /etc/anacrontab:
+Let us use cron.daily to illustrate the run process of /etc/anacrontab:
 
-1. `anacron` reads the ** /var/spool/anacron/cron.daily ** file, and the content of the file shows the time of the last execution.
-2. Compared with the current time, if the difference between the two times exceeds 1 day, the cron.daily job will be executed.
-3. This work can only be performed from 03:00-22:00.
-4. Check whether a file is executed after 5 minutes after booting. When the first one is executed, it will be randomly delayed for 0～45 minutes to execute the next one.
-5. Use the nice parameter to specify the default priority, and use the run-parts parameter to execute all executable files in the /etc/cron.daily/ directory.
+1. `anacron` reads the ** /var/spool/anacron/cron.daily ** file, and the content of the file shows the time of the last run.
+2. Compared with the current time, if the difference between the two times exceeds 1 day, the cron.daily job will run.
+3. This work can only run from 03:00-22:00.
+4. Verify whether a file runs after 5 minutes after booting. When the first one runs, it will be randomly delayed for 0～45 minutes to run the next one.
+5. Use the nice parameter to specify the default priority, and use the run-parts parameter to run all executable files in the /etc/cron.daily/ directory.
 
 ## Related Commands
 
 Use the command `anacron`, commonly used options are:
 
 | Options | Description |
 | --- | --- |
-| -f | Execute all jobs, ignoring timestamps |
+| -f | Run all jobs, ignoring timestamps |
 | -u | Update the timestamp to the current time without performing any action |
 | -T | Test the validity of the configuration file /etc/anacrontab |
 
-For more help information, please [Browse the manual page](https://man7.org/linux/man-pages/man8/anacron.8.html)
+For more help information, [browse the manual page](https://man7.org/linux/man-pages/man8/anacron.8.html)

docs/guides/automation/cron_jobs_howto.md

@@ -13,31 +13,30 @@ tags:
 
 ## Prerequisites
 
-* A machine running Rocky Linux
-* Some comfort with modifying configuration files from the command-line using your favorite editor (`vi` is used here)
+* A computer running Rocky Linux
+* Some comfort with modifying configuration files from the command-line by using your favorite editor (using `vi` here)
 
 ## <a name="assumptions"></a> Assumptions
 
-* Basic knowledge of bash, python, or other scripting/programming tools, and the desire to have a script run automatically
+* Basic knowledge of bash, python, or other scripting or programming tools, and you want to have a script run automatically
 * That you are either running as the root user or have switched to root with `sudo -s`  
 **(You can run certain scripts in your own directories as your own user. In this case, switching to root is not necessary.)**
-* We assume that you're pretty cool.
 
 ## Introduction
 
-Linux provides the _cron_ system, a time-based job scheduler, for automating processes. It's simple and yet quite powerful. Want a script or program to run every day at 5 PM? This is where you set that up.
+Linux provides the _cron_ system, a time-based job scheduler, for automating processes. It is simplistic and yet quite powerful. Want a script or program to run every day at 5 PM? This is where you set that up.
 
-The _crontab_ is essentially a list where users add their own automated tasks and jobs, and it has a number of options that can simplify things even further. This document will explore some of these. It's a good refresher for those with some experience, and new users can add the `cron` system to their repertoire.
+The _crontab_ is essentially a list where users add their own automated tasks and jobs, and it has many options that can simplify things even further. This document will explore some of these. It is a good refresher for those with some experience, and new users can add the `cron` system to their repertoire.
 
-`anacron` is discussed briefly here in reference to the `cron` "dot" directories. `anacron` is run by `cron`, and is advantageous for machines that are not up all the time, such as workstations and laptops. The reason for this is that while `cron` runs jobs on a schedule, if the machine is off when the job is scheduled, the job does not run. With `anacron` the job is picked up and run when the machine is on again, even if the scheduled run was in the past. `anacron` though, uses a more randomized approach to running tasks where the timing is not exact. This makes sense for workstations and laptops, but not so much for servers.  This can be a problem for things like server backups, for instance, that need to run at a specific time. That's where `cron` continues to provide the best solution for server administrators. All that being said, server administrators and workstation or laptop users can gain something from both approaches. You can easily mix and match based on your needs.  For more information on `anacron` see [anacron - Automating commands](anacron.md).
+`anacron` is discussed briefly here in reference to the `cron` "dot" directories. `anacron` is run by `cron`, and is helpful for machines that are not up all the time, such as workstations and laptops. The reason for this is that while `cron` runs jobs on a schedule, if the machine is off when the job is scheduled, the job does not run. With `anacron` the job is picked up and run when the machine is on again, even if the scheduled run was in the past. `anacron` though, uses a more randomized approach to running tasks where the timing is not exact. This makes sense for workstations and laptops, but not so much for servers. This can be a problem for things such as server backups, for instance, needing to run a job at a specific time. That is where `cron` provides the best solution for server administrators. Still, server administrators and workstation or notebook users can gain something from both approaches. You can mix and match based on your needs. For more on `anacron` see [anacron - Automating commands](anacron.md).
 
 ### <a name="starting-easy"></a>Starting Easy - The `cron` Dot Directories
 
-Built into every Linux system for many versions now, the `cron` "dot" directories help to automate processes quickly. These show up as directories that the `cron` system calls based on their naming conventions. They are called differently, however, based on which process is assigned to call them, `anacron` or `cron`. The default behavior is to use `anacron`, but this can be changed by a server, workstation or laptop administrator.
+Built into every Linux system for many versions now, the `cron` "dot" directories help to automate processes quickly. These show up as directories that the `cron` system calls based on their naming conventions. They are run differently, however, based on the process assigned to call them, `anacron` or `cron`. The default behavior is to use `anacron`, but this can be changed by a server, workstation or notebook administrator.
 
 #### <a name="for_servers"></a>For Servers
 
-As stated in the introduction, `cron` normally runs `anacron` these days to execute scripts in these "dot" directories. You *may*, though, want to use these "dot" directories on servers as well, and if that is the case, then there are two steps that you can take to make sure that these "dot" directories are run on a strict schedule. To do so, we need to install a package and remove another one:
+As stated in the introduction, `cron` normally runs `anacron` these days to run scripts in these "dot" directories. You *may*, want to use these "dot" directories on servers as well, and if that is the case, there are two steps that you can take to verify that these "dot" directories run on a strict schedule. To do this, you need to install a package and remove another one:
 
 `dnf install cronie-noanacron`
 
@@ -67,7 +66,7 @@ This translates to the following:
 
 #### <a name="for_workstations"></a>For Workstations
 
-If you want to run scripts on a workstation or laptop in the `cron` "dot" directories, then there is nothing special that you need to do. Simply copy your script file into the directory in question, and make sure it is executable. Here are the directories:
+If you want to run scripts on a workstation or notebook in the `cron` "dot" directories, nothing special is needed. Just copy your script file into the directory in question, and make sure it is executable. Here are the directories:
 
 * `/etc/cron.hourly` - Scripts placed here will run one minute past the hour every hour. (this is run by `cron` regardless of whether `anacron` is installed or not)
 * `/etc/cron.daily` - Scripts placed here will run every day. `anacron` adjusts the timing of these. (see tip)
@@ -78,15 +77,15 @@ If you want to run scripts on a workstation or laptop in the `cron` "dot" direct
 
     These are likely to be run at similar (but not exactly the same) times every day, week, and month. For more exact running times, see the @options below.
 
-So provided you're alright with just letting the system auto-run your scripts, and allowing them to run sometime during the specified period, then it makes it very easy to automate tasks.
+Provided you are good with just letting the system auto-run your scripts, and allowing them to run sometime during the specified time, it simplifies the automation of tasks.
 
 !!! note
 
     There is no rule that says a server administrator cannot use the randomized run times which `anacron` uses to run scripts in the "dot" directories. The use case for this would be for a script that is not time sensitive.
 
 ### Create Your Own `cron`
 
-Of course, if the automated, randomized times don't work well in [For Workstations above](#for-workstations), and the scheduled times in the [For Servers above](#for-servers), then you can create your own. In this example, we are assuming you are doing this as root. [see Assumptions](#assumptions) To do this, type the following:
+If the automated, randomized times do not work well in [For Workstations above](#for-workstations), and the scheduled times in the [For Servers above](#for-servers), then you can create your own. In this example, we are assuming you are doing this as root. [see Assumptions](#assumptions) To do this, type the following:
 
 `crontab -e`
 
@@ -118,19 +117,19 @@ This will pull up root user's `crontab` as it exists at this moment in your chos
 # m h  dom mon dow   command
 ```
 
-Notice that this particular `crontab` file has some of its own documentation built-in. That isn't always the case. When modifying a `crontab` on a container or minimalist operating system, the `crontab` will be an empty file unless an entry has already been placed in it.
+Notice that this particular `crontab` file has some of its own documentation built-in. That is not always the case. When modifying a `crontab` on a container or minimalist operating system, the `crontab` will be an empty file unless an entry is in it.
 
-Let's assume that we have a backup script that we want to run at 10 PM at night. The `crontab` uses a 24 hour clock, so this would be 22:00. Let's assume that the backup script is called "backup" and that it is currently in the _/usr/local/sbin_ directory.
+Assume that you have a backup script that you want to run at 10 PM at night. The `crontab` uses a 24 hour clock, this would be 22:00. Assume that the backup script is called "backup" and that it is currently in the _/usr/local/sbin_ directory.
 
 !!! note
 
     Remember that this script needs to also be executable (`chmod +x`) in order for the `cron` to run it.
 
-To add the job, we would:
+To add the job, you:
 
 `crontab -e`
 
-`crontab` stands for "cron table" and the format of the file is, in fact, a loose table layout. Now that we are in the `crontab`, go to the bottom of the file and add your new entry. If you are using `vi` as your default system editor, then this is done with the following keys:
+`crontab` stands for "cron table" and the format of the file is, in fact, a loose table layout. Now that you are in the `crontab`, go to the bottom of the file and add your new entry. If you are using `vi` as your default system editor, then this is done with the following keys:
 
 `Shift : $`
 
@@ -144,11 +143,11 @@ To run our backup script every day at 10:00, the entry would look like this:
 
 `00  22  *  *  *   /usr/local/sbin/backup`
 
-This says run the script at 10 PM, every day of the month, every month, and every day of the week. Obviously, this is a pretty simple example and things can get quite complicated when you need specifics.
+This says run the script at 10 PM, every day of the month, every month, and every day of the week. This is a simplistic example and things can get quite complicated when you need specifics.
 
 ### The @options for `crontab`
 
-Another way to run jobs at a strictly scheduled time (i.e., day, week, month, year, etc.) is to use the @options, which offer the ability to use more natural timing. The @options consist of:
+Another way to run jobs at a strictly scheduled time (i.e., day, week, month, year, and so on.) is to use the @options, which offer the ability to use more natural timing. The @options consist of:
 
 * `@hourly` runs the script every hour of every day at 0 minutes past the hour. (this is exactly the result of placing your script in `/etc/cron.hourly` too)
 * `@daily` runs the script every day at midnight.
@@ -167,27 +166,27 @@ For our backup script example, if we use the @daily option to run the backup scr
 
 ### More Complex Options
 
-So far, everything we have talked about has had pretty simple options, but what about the more complex task timings? Let's say that you want to run your backup script every 10 minutes during the day (probably not a very practical thing to do, but hey, this is an example!). To do this you would write:
+So far, everything we have talked about has had pretty simplistic options, but what about the more complex task timings? Say that you want to run your backup script every 10 minutes during the day (probably not a practical thing to do, but hey, this is an example!). To do this you would write:
 
 `*/10  *   *   *   *   /usr/local/sbin/backup`
 
-What if you wanted to run the backup every 10 minutes, but only on Monday, Wednesday and Friday?:
+What if you wanted to run the backup every 10 minutes, but only on Monday, Wednesday, and Friday?:
 
 `*/10  *   *   *   1,3,5   /usr/local/sbin/backup`
 
 What about every 10 minutes every day except Saturday and Sunday?:
 
 `*/10  *   *   *    1-5    /usr/local/sbin/backup`
 
-In the table, the commas let you specify individual entries within a field, while the dash lets you specify a range of values within a field. This can happen in any of the fields, and on multiple fields at the same time. As you can see, things can get pretty complicated.
+In the table, the commas lets you specify individual entries within a field,  and the dash lets you specify a range of values within a field. This can happen in any of the fields, and on many fields at the same time. As you can see, things can get pretty complicated.
 
 When determining when to run a script, you need to take time and plan it out, particularly if the criteria are complex.
 
 ## Conclusions
 
-The _cron/crontab_ system is a very powerful tool for the Rocky Linux systems administrator or desktop user. It can allow you to automate tasks and scripts so that you don't have to remember to run them manually. There are more examples provided here:
+The _cron/crontab_ system is a powerful tool for the Rocky Linux systems administrator or desktop user. It allows you to automate tasks and scripts so that you do not have to remember to run them manually. There are more examples provided here:
 
 * For machines that are **not** on 24 hours a day, explore [anacron - Automating commands](anacron.md).
 * For a concise description of `cron` processes, check out [cronie - Timed Tasks](cronie.md)
 
-While the basics are pretty easy, you can get a lot more complex. For more information on `crontab` head up to the [crontab manual page](https://man7.org/linux/man-pages/man5/crontab.5.html). On most systems, you can also enter `man crontab` for additional command details. You can also simply do a web search for "crontab" which will give you a wealth of results to help you fine-tune your `crontab` skills.
+While the basics are pretty easy, you can get more complex. For more information on `crontab` head up to the [crontab manual page](https://man7.org/linux/man-pages/man5/crontab.5.html). On most systems, you can also enter `man crontab` for additional command details. You can also do a web search for "crontab" which will give you a wealth of results to help you fine-tune your `crontab` skills.