mirror of
https://github.com/ansible-collections/community.general.git
synced 2026-05-07 22:02:50 +00:00
Avoid having module documentation links to itself (#21329)
* Avoid having module documentation links to itself A lot of modules use M(own_module) in their documentation causing a link in the documentation to itself. * Make note more clear now
This commit is contained in:
committed by
John R Barker
parent
fb32c19fea
commit
f824b2ce8d
@@ -29,7 +29,7 @@ module: win_command
|
||||
short_description: Executes a command on a remote Windows node
|
||||
version_added: 2.2
|
||||
description:
|
||||
- The M(win_command) module takes the command name followed by a list of space-delimited arguments.
|
||||
- The C(win_command) module takes the command name followed by a list of space-delimited arguments.
|
||||
- The given command will be executed on all selected nodes. It will not be
|
||||
processed through the shell, so variables like C($env:HOME) and operations
|
||||
like C("<"), C(">"), C("|"), and C(";") will not work (use the M(win_shell)
|
||||
@@ -52,7 +52,7 @@ options:
|
||||
notes:
|
||||
- If you want to run a command through a shell (say you are using C(<),
|
||||
C(>), C(|), etc), you actually want the M(win_shell) module instead. The
|
||||
M(win_command) module is much more secure as it's not affected by the user's
|
||||
C(win_command) module is much more secure as it's not affected by the user's
|
||||
environment.
|
||||
- " C(creates), C(removes), and C(chdir) can be specified after the command. For instance, if you only want to run a command if a certain file does not exist, use this."
|
||||
author:
|
||||
|
||||
@@ -29,7 +29,7 @@ module: win_copy
|
||||
version_added: "1.9.2"
|
||||
short_description: Copies files to remote locations on windows hosts.
|
||||
description:
|
||||
- The M(win_copy) module copies a file on the local box to remote windows locations.
|
||||
- The C(win_copy) module copies a file on the local box to remote windows locations.
|
||||
options:
|
||||
src:
|
||||
description:
|
||||
|
||||
@@ -29,7 +29,7 @@ module: win_shell
|
||||
short_description: Execute shell commands on target hosts.
|
||||
version_added: 2.2
|
||||
description:
|
||||
- The M(win_shell) module takes the command name followed by a list of space-delimited arguments.
|
||||
- The C(win_shell) module takes the command name followed by a list of space-delimited arguments.
|
||||
It is similar to the M(win_command) module, but runs
|
||||
the command via a shell (defaults to PowerShell) on the target host.
|
||||
options:
|
||||
@@ -53,7 +53,7 @@ options:
|
||||
notes:
|
||||
- If you want to run an executable securely and predictably, it may be
|
||||
better to use the M(win_command) module instead. Best practices when writing
|
||||
playbooks will follow the trend of using M(win_command) unless M(win_shell) is
|
||||
playbooks will follow the trend of using M(win_command) unless C(win_shell) is
|
||||
explicitly required. When running ad-hoc commands, use your best judgement.
|
||||
- WinRM will not return from a command execution until all child processes created have exited. Thus, it is not possible to use win_shell to spawn long-running child or background processes.
|
||||
Consider creating a Windows service for managing background processes.
|
||||
|
||||
Reference in New Issue
Block a user