Bug in shell module? Wrong syntax not noticed

[Johannes Kastl]

Dear all,

I stumbled upon this code, because it was not idempotent and reported
as changed each time I ran the playbook:

- name: "copy file"
shell: "cp /some/path/to/a/file.txt /home/foobar/some/other/path"
args:
creates="/home/foobar/some/other/path/file.txt"

Somehow I had missed that the creates argument is to be given with a
colon, not with an equal sign. When using a colon, this task is
idempotent.

Should this syntax error not be detected somehow? Or is this (by
coincidence) valid YAML? The shell module does not respect the setting
with an equal sign, only with a colon.

Johannes

[Brian Coca]

​the problem is you are mixing syntax:

this is valid:

​- name: "copy file"

  shell: "cp /some/path/to/a/file.txt /home/foobar/some/other/path creates="/home/foobar/some/other/path/file.txt"

this is also valid:

- name: "copy file"

  shell: "cp /some/path/to/a/file.txt /home/foobar/some/other/path"

  args:

    creates: "/home/foobar/some/other/path/file.txt"

args won't give you an error in the case you showed as you passed a string to the shell module which allows for arbitrary strings (shell commands). To the shell that would have appeared as setting a variable inline or an extra parameter.

----------

Brian Coca

[Johannes Kastl]

On 02.06.16 00:35 Brian Coca wrote:

> args won't give you an error in the case you showed as you passed a string
> to the shell module which allows for arbitrary strings (shell commands). To
> the shell that would have appeared as setting a variable inline or an extra
> parameter.

But I would have thought that as soon as an 'args:' appears, the shell
module should get that the following is syntax-with-colon and throw an
error otherwise.

Or do you mean that creates=foo could be a valid argument? But all
arguments to the shell module should declare something (a=b), not just
switch something on or off (disable_foo).

Johannes

[Brian Coca]

modules don't read args, ansible does, then passes them to the module, since the shell module is 'free form' there is really nothing to validate against, since what you are passing can work in a shell .. there is no error thrown either.

----------

Brian Coca

[Johannes Kastl]

I'll reword my thought:

If ansible is doing the parsing, it already distinguishes between the
two syntax methods (the one with one line and all stuff and the other
one where there is a line containing 'args:' and some more lines).

IMHO it should note that as soon as the 'args:' appears, everything
after that should be in declarative syntax (foo: bar) and every line
not containing a colon is wrong syntax.

Johannes