In case paths contain spaces, it's better to consistently quote
variables, and to use $() instead of `` for external invocations.
Signed-off-by: martin f. krafft <madduck@madduck.net>
dirname/basename do not need an external process, shell variable
expansion can be made to do the same a bit faster.
Signed-off-by: martin f. krafft <madduck@madduck.net>
The env-setup script is not intended to be run directly, so it does not
need a shebang line, which might even create the wrong expectations.
Signed-off-by: martin f. krafft <madduck@madduck.net>
- The html_ify filter now escapes HTML found in module documentation.
THIS COULD AFFECT MORE THAN JUST MARKDOWN but I didn't see any modules
expecting to use e.g. HTML entities or HTML tags in their
documentation.
- The markdown_ify filter (used as jpfunc in markdown.j2) escapes at
least a few Markdown in-line formatting characters.
- Improvements to markdown.j2:
- Call jpfunc on the module name heading so that it gets escaped for
Markdown (e.g. my_module_name becomes my\_module\_name).
- Added paragraph breaks between paragraphs in the description.
- Added examples heading, which is consistent with the notes heading
below it.
'source' is actually a "bashism" and the POSIX-way of sourcing a file
uses the single dot (which is arguably less readable). Both yield the
same result, and since the script may now also be sourced from
within the hacking directory, this commit expands the usage synopsis
accordingly.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Conflicts:
hacking/env-setup
Bash needs a special case to determine the dirname of the sourced path
(the hacking dir), but in all other cases, using $0 allows the script to
be sourced also from within the hacking directory, not only from its
parent.
Signed-off-by: martin f. krafft <madduck@madduck.net>
The text parameter can contain non-ASCII characters, so we'll encode it
using UTF-8. For example the DOCUMENTATION of the bzr module has such
characters in the name of the author.
At the moment Ansible prefers yes/no for module booleans, however booleans in playbooks are still using True/False, rather than yes/no. This changes modifies boolean uses in playbooks (and man pages) to favor yes/no rather than True/False.
This change includes:
- Adaptation of documentation and examples to favor yes/no
- Modification to manpage output to favor yes/no (the docsite output already favors yes/no)
Add HTML-escaping to code examples in rST tempate of module-formatter
Add support for specifying port, addresses with phrases and attaching files
Add support for custom headers and document version_added for new options
X-Mailer header added :)
protect empty address lists & attachment list, and add bcc
Add constant DEFAULT_MODULE_LANG that defaults to C. Can be set via
environment variable ANSIBLE_MODULE_LANG or configuration variable
module_lang. Updated test-module to have same behavior.
Update constants.py so that one can specify environmental variable
ANSIBLE_SYSLOG_FACILITY or syslog_facility in ansible.cfg to define
the syslog facility to use. Alternatively, you can specify
ansible_syslog_facility in inventory. Runner now replaces
the syslog facility in the openlog() call with the default or
the injected variables ansible_syslog_facility.
This also updates hacking/test-module to behave similarly.
- fixed template (it was the template), adding indentation with Jinja2
- added description of code examples to man-page template (was missing)
- fixed fireball, cron, and debug module examples to confrom
Try to autodetect MODULEDIR, instead of hardcoded path in jpmens
homedir.
Check if MODULEDIR exists; exit if it doesn't.
Rewrite boilerplate() to use DOCUMENTATION.yaml in examples/. This
makes use of tbielawa's recent change that added this example file.
This also fixes -G so that it works. boilerplate() was commented out
before.
On RHEL5 and RHEL6 there is not argparse, and 'make rpm' fails because of this.
With this change it works, and I can test and fix my own documentation...
should be a huge reduction of total ansible source, at a slight cost of difficulty in original module development.
We need to apply this now to all modules, but may need to have some exemptions to things like command, which should
subclass this module.