Fixing ad-hoc commands #73636 (#73646)

docs/docsite/rst/network/getting_started/network_differences.rst

@@ -10,7 +10,7 @@ Network automation leverages the basic Ansible concepts, but there are important
 Execution on the control node
 ================================================================================
 
-Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad-hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs.
+Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs.
 
 Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory.
 

docs/docsite/rst/network/user_guide/network_debug_troubleshooting.rst

@@ -160,9 +160,9 @@ As with any effort to troubleshoot it's important to simplify the test case as m
 For Ansible this can be done by ensuring you are only running against one remote device:
 
 * Using ``ansible-playbook --limit switch1.example.net...``
-* Using an ad-hoc ``ansible`` command
+* Using an ad hoc ``ansible`` command
 
-`ad-hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::
+`ad hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::
 
   ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k
 

docs/docsite/rst/plugins/callback.rst

@@ -53,7 +53,7 @@ or for my custom callback:
 
 This only affects :ref:`ansible-playbook` by default.
 
-Setting a callback plugin for ad-hoc commands
+Setting a callback plugin for ad hoc commands
 ---------------------------------------------
 
 The :ref:`ansible` ad hoc command specifically uses a different callback plugin for stdout,

docs/docsite/rst/reference_appendices/faq.rst

@@ -352,7 +352,7 @@ How do I see a list of all of the ansible\_ variables?
 
 Ansible by default gathers "facts" about the machines under management, and these facts can be accessed in playbooks
 and in templates. To see a list of all of the facts that are available about a machine, you can run the ``setup`` module
-as an ad-hoc action:
+as an ad hoc action:
 
 .. code-block:: shell-session
 
@@ -519,7 +519,7 @@ and distribution and local configuration.
 How do I generate encrypted passwords for the user module?
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-Ansible ad-hoc command is the easiest option:
+Ansible ad hoc command is the easiest option:
 
 .. code-block:: shell-session
 

docs/docsite/rst/reference_appendices/general_precedence.rst

@@ -47,7 +47,7 @@ When you type something directly at the command line, you may feel that your han
 
 You can override all other settings from all other sources in all other precedence categories at the command line by  :ref:`general_precedence_extra_vars`, but that is not a command-line option, it is a way of passing a :ref:`variable<general_precedence_variables>`.
 
-At the command line, if you pass multiple values for a parameter that accepts only a single value, the last defined value wins. For example, this :ref:`ad-hoc task<intro_adhoc>` will connect as ``carol``, not as ``mike``::
+At the command line, if you pass multiple values for a parameter that accepts only a single value, the last defined value wins. For example, this :ref:`ad hoc task<intro_adhoc>` will connect as ``carol``, not as ``mike``::
 
       ansible -u mike -m ping myhost -u carol
 

docs/docsite/rst/scenario_guides/guide_cloudstack.rst

@@ -27,7 +27,7 @@ Or alternatively starting with Debian 9 and Ubuntu 16.04:
 
     $ sudo apt install python-cs
 
-.. note:: cs also includes a command line interface for ad-hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``.
+.. note:: cs also includes a command line interface for ad hoc interaction with the CloudStack API, for example ``$ cs listVirtualMachines state=Running``.
 
 Limitations and Known Issues
 ````````````````````````````

docs/docsite/rst/scenario_guides/guide_rax.rst

@@ -100,7 +100,7 @@ The 'rax' module provides the ability to provision instances within Rackspace Cl
    them as module arguments, or by specifying the location of a credentials
    file.
 
-Here is a basic example of provisioning an instance in ad-hoc mode:
+Here is a basic example of provisioning an instance in ad hoc mode:
 
 .. code-block:: bash
 

docs/docsite/rst/shared_snippets/basic_concepts.txt

@@ -26,7 +26,7 @@ The units of code Ansible executes. Each module has a particular use, from admin
 Tasks
 =====
 
-The units of action in Ansible. You can execute a single task once with an ad-hoc command.
+The units of action in Ansible. You can execute a single task once with an ad hoc command.
 
 Playbooks
 =========

docs/docsite/rst/user_guide/index.rst

@@ -21,7 +21,7 @@ Getting started
   * a :ref:`text introduction <intro_getting_started>`
 
 * I'm ready to learn about Ansible. What :ref:`basic_concepts` do I need to learn?
-* I want to use Ansible without writing a playbook. How do I use :ref:`ad-hoc commands <intro_adhoc>`?
+* I want to use Ansible without writing a playbook. How do I use :ref:`ad hoc commands <intro_adhoc>`?
 
 Writing tasks, plays, and playbooks
 ===================================

docs/docsite/rst/user_guide/intro.rst

@@ -3,7 +3,7 @@
 Introduction
 ============
 
-Before we start exploring the main components of Ansible -- playbooks, configuration management, deployment, and orchestration -- we'll learn how to get Ansible installed and cover some basic concepts.  We'll also go over how to execute ad-hoc commands in parallel across your nodes using /usr/bin/ansible, and see what modules are available in Ansible's core (you can also write your own, which is covered later).
+Before we start exploring the main components of Ansible -- playbooks, configuration management, deployment, and orchestration -- we'll learn how to get Ansible installed and cover some basic concepts.  We'll also go over how to execute ad hoc commands in parallel across your nodes using /usr/bin/ansible, and see what modules are available in Ansible's core (you can also write your own, which is covered later).
 
 .. toctree::
    :maxdepth: 1

docs/docsite/rst/user_guide/intro_adhoc.rst

@@ -1,18 +1,18 @@
 .. _intro_adhoc:
 
 *******************************
-Introduction to ad-hoc commands
+Introduction to ad hoc commands
 *******************************
 
-An Ansible ad-hoc command uses the `/usr/bin/ansible` command-line tool to automate a single task on one or more managed nodes. Ad-hoc commands are quick and easy, but they are not reusable. So why learn about ad-hoc commands first? Ad-hoc commands demonstrate the simplicity and power of Ansible. The concepts you learn here will port over directly to the playbook language. Before reading and executing these examples, please read :ref:`intro_inventory`.
+An Ansible ad hoc command uses the `/usr/bin/ansible` command-line tool to automate a single task on one or more managed nodes. ad hoc commands are quick and easy, but they are not reusable. So why learn about ad hoc commands first? ad hoc commands demonstrate the simplicity and power of Ansible. The concepts you learn here will port over directly to the playbook language. Before reading and executing these examples, please read :ref:`intro_inventory`.
 
 .. contents::
    :local:
 
-Why use ad-hoc commands?
+Why use ad hoc commands?
 ========================
 
-Ad-hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad-hoc command looks like this:
+ad hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad hoc command looks like this:
 
 .. code-block:: bash
 
@@ -20,17 +20,17 @@ Ad-hoc commands are great for tasks you repeat rarely. For example, if you want
 
 You can learn more about :ref:`patterns<intro_patterns>` and :ref:`modules<working_with_modules>` on other pages.
 
-Use cases for ad-hoc tasks
+Use cases for ad hoc tasks
 ==========================
 
-Ad-hoc tasks can be used to reboot servers, copy files, manage packages and users, and much more. You can use any Ansible module in an ad-hoc task. Ad-hoc tasks, like playbooks, use a declarative model,
+ad hoc tasks can be used to reboot servers, copy files, manage packages and users, and much more. You can use any Ansible module in an ad hoc task. ad hoc tasks, like playbooks, use a declarative model,
 calculating and executing the actions required to reach a specified final state. They
 achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state.
 
 Rebooting servers
 -----------------
 
-The default module for the ``ansible`` command-line utility is the :ref:`ansible.builtin.command module<command_module>`. You can use an ad-hoc task to call the command module and reboot all web servers in Atlanta, 10 at a time. Before Ansible can do this, you must have all servers in Atlanta listed in a group called [atlanta] in your inventory, and you must have working SSH credentials for each machine in that group. To reboot all the servers in the [atlanta] group:
+The default module for the ``ansible`` command-line utility is the :ref:`ansible.builtin.command module<command_module>`. You can use an ad hoc task to call the command module and reboot all web servers in Atlanta, 10 at a time. Before Ansible can do this, you must have all servers in Atlanta listed in a group called [atlanta] in your inventory, and you must have working SSH credentials for each machine in that group. To reboot all the servers in the [atlanta] group:
 
 .. code-block:: bash
 
@@ -79,7 +79,7 @@ evaluate the variable on the box you were on.
 Managing files
 --------------
 
-An ad-hoc task can harness the power of Ansible and SCP to transfer many files to multiple machines in parallel. To transfer a file directly to all servers in the [atlanta] group:
+An ad hoc task can harness the power of Ansible and SCP to transfer many files to multiple machines in parallel. To transfer a file directly to all servers in the [atlanta] group:
 
 .. code-block:: bash
 
@@ -112,7 +112,7 @@ As well as delete directories (recursively) and delete files:
 Managing packages
 -----------------
 
-You might also use an ad-hoc task to install, update, or remove packages on managed nodes using a package management module like yum. To ensure a package is installed without updating it:
+You might also use an ad hoc task to install, update, or remove packages on managed nodes using a package management module like yum. To ensure a package is installed without updating it:
 
 .. code-block:: bash
 
@@ -143,7 +143,7 @@ Ansible has modules for managing packages under many platforms. If there is no m
 Managing users and groups
 -------------------------
 
-You can create, manage, and remove user accounts on your managed nodes with ad-hoc tasks:
+You can create, manage, and remove user accounts on your managed nodes with ad hoc tasks:
 
 .. code-block:: bash
 
@@ -182,7 +182,7 @@ Ensure a service is stopped:
 Gathering facts
 ---------------
 
-Facts represent discovered variables about a system. You can use facts to implement conditional execution of tasks but also just to get ad-hoc information about your systems. To see all facts:
+Facts represent discovered variables about a system. You can use facts to implement conditional execution of tasks but also just to get ad hoc information about your systems. To see all facts:
 
 .. code-block:: bash
 

docs/docsite/rst/user_guide/intro_getting_started.rst

@@ -10,7 +10,7 @@ Now that you have read the :ref:`installation guide<installation_guide>` and ins
 * connects to those machines (or network devices, or other managed nodes), usually over SSH
 * copies one or more modules to the remote machines and starts execution there
 
-Ansible can do much more, but you should understand the most common use case before exploring all the powerful configuration, deployment, and orchestration features of Ansible. This page illustrates the basic process with a simple inventory and an ad-hoc command. Once you understand how Ansible works, you can read more details about :ref:`ad-hoc commands<intro_adhoc>`, organize your infrastructure with :ref:`inventory<intro_inventory>`, and harness the full power of Ansible with :ref:`playbooks<playbooks_intro>`.
+Ansible can do much more, but you should understand the most common use case before exploring all the powerful configuration, deployment, and orchestration features of Ansible. This page illustrates the basic process with a simple inventory and an ad hoc command. Once you understand how Ansible works, you can read more details about :ref:`ad hoc commands<intro_adhoc>`, organize your infrastructure with :ref:`inventory<intro_inventory>`, and harness the full power of Ansible with :ref:`playbooks<playbooks_intro>`.
 
 .. contents::
    :local:
@@ -18,7 +18,7 @@ Ansible can do much more, but you should understand the most common use case bef
 Selecting machines from inventory
 =================================
 
-Ansible reads information about which machines you want to manage from your inventory. Although you can pass an IP address to an ad-hoc command, you need inventory to take advantage of the full flexibility and repeatability of Ansible.
+Ansible reads information about which machines you want to manage from your inventory. Although you can pass an IP address to an ad hoc command, you need inventory to take advantage of the full flexibility and repeatability of Ansible.
 
 Action: create a basic inventory
 --------------------------------
@@ -111,7 +111,7 @@ If you need privilege escalation (sudo and similar) to run a command, pass the `
 
 You can read more about privilege escalation in :ref:`become`.
 
-Congratulations! You have contacted your nodes using Ansible. You used a basic inventory file and an ad-hoc command to direct Ansible to connect to specific remote nodes, copy a module file there and execute it, and return output. You have a fully working infrastructure.
+Congratulations! You have contacted your nodes using Ansible. You used a basic inventory file and an ad hoc command to direct Ansible to connect to specific remote nodes, copy a module file there and execute it, and return output. You have a fully working infrastructure.
 
 Resources
 =================================

docs/docsite/rst/user_guide/intro_patterns.rst

@@ -3,7 +3,7 @@
 Patterns: targeting hosts and groups
 ====================================
 
-When you execute Ansible through an ad-hoc command or by running a playbook, you must choose which managed nodes or groups you want to execute against. Patterns let you run commands and playbooks against specific hosts and/or groups in your inventory. An Ansible pattern can refer to a single host, an IP address, an inventory group, a set of groups, or all hosts in your inventory. Patterns are highly flexible - you can exclude or require subsets of hosts, use wildcards or regular expressions, and more. Ansible executes on all inventory hosts included in the pattern.
+When you execute Ansible through an ad hoc command or by running a playbook, you must choose which managed nodes or groups you want to execute against. Patterns let you run commands and playbooks against specific hosts and/or groups in your inventory. An Ansible pattern can refer to a single host, an IP address, an inventory group, a set of groups, or all hosts in your inventory. Patterns are highly flexible - you can exclude or require subsets of hosts, use wildcards or regular expressions, and more. Ansible executes on all inventory hosts included in the pattern.
 
 .. contents::
    :local:
@@ -11,7 +11,7 @@ When you execute Ansible through an ad-hoc command or by running a playbook, you
 Using patterns
 --------------
 
-You use a pattern almost any time you execute an ad-hoc command or a playbook. The pattern is the only element of an :ref:`ad-hoc command<intro_adhoc>` that has no flag. It is usually the second element::
+You use a pattern almost any time you execute an ad hoc command or a playbook. The pattern is the only element of an :ref:`ad hoc command<intro_adhoc>` that has no flag. It is usually the second element::
 
     ansible <pattern> -m <module_name> -a "<module options>"
 
@@ -31,7 +31,7 @@ For example::
     - name: restart webservers
       hosts: webservers
 
-Since you often want to run a command or playbook against multiple hosts at once, patterns often refer to inventory groups. Both the ad-hoc command and the playbook above will execute against all machines in the ``webservers`` group.
+Since you often want to run a command or playbook against multiple hosts at once, patterns often refer to inventory groups. Both the ad hoc command and the playbook above will execute against all machines in the ``webservers`` group.
 
 .. _common_patterns:
 

docs/docsite/rst/user_guide/playbooks_async.rst

@@ -8,10 +8,10 @@ By default Ansible runs tasks synchronously, holding the connection to the remot
 .. contents::
    :local:
 
-Asynchronous ad-hoc tasks
+Asynchronous ad hoc tasks
 -------------------------
 
-You can execute long-running operations in the background with :ref:`ad-hoc tasks <intro_adhoc>`. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``)::
+You can execute long-running operations in the background with :ref:`ad hoc tasks <intro_adhoc>`. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``)::
 
     $ ansible all -B 3600 -P 0 -a "/usr/bin/long_running_operation --do-stuff"
 

docs/docsite/rst/user_guide/sample_setup.rst

@@ -234,7 +234,7 @@ To reconfigure only the first 10 webservers in Boston, and then the next 10::
     ansible-playbook -i production webservers.yml --limit boston[0:9]
     ansible-playbook -i production webservers.yml --limit boston[10:19]
 
-The sample setup also supports basic ad-hoc commands::
+The sample setup also supports basic ad hoc commands::
 
     ansible boston -i production -m ping
     ansible boston -i production -m command -a '/sbin/reboot'

docs/docsite/rst/user_guide/vault.rst

@@ -9,7 +9,7 @@ Ansible Vault encrypts variables and files so you can protect sensitive content
 .. warning::
     * Encryption with Ansible Vault ONLY protects 'data at rest'.  Once the content is decrypted ('data in use'), play and plugin authors are responsible for avoiding any secret disclosure, see :ref:`no_log <keep_secret_data>` for details on hiding output and :ref:`vault_securing_editor` for security considerations on editors you use with Ansible Vault.
 
-You can use encrypted variables and files in ad-hoc commands and playbooks by supplying the passwords you used to encrypt them. You can modify your ``ansible.cfg`` file to specify the location of a password file or to always prompt for the password.
+You can use encrypted variables and files in ad hoc commands and playbooks by supplying the passwords you used to encrypt them. You can modify your ``ansible.cfg`` file to specify the location of a password file or to always prompt for the password.
 
 .. contents::
    :local:

docs/docsite/rst/user_guide/windows_usage.rst

@@ -433,7 +433,7 @@ This example shows the use of single quotes when they are required::
 
 Legacy key=value Style
 ----------------------
-The legacy ``key=value`` syntax is used on the command line for ad-hoc commands,
+The legacy ``key=value`` syntax is used on the command line for ad hoc commands,
 or inside playbooks. The use of this style is discouraged within playbooks
 because backslash characters need to be escaped, making playbooks harder to read.
 The legacy syntax depends on the specific implementation in Ansible, and quoting