Passing arguments using ansible-builtin-command

Get Help
1

I have a command that takes arguments in the form: mycommand --myarg1=myargvalue --myarg2=‘{“mytags”: [{“myint1”: 12345, “mystr1”: “fubarbaz”}]}’

I created one variable with “–myarg1=myargvalue”. That works fine. I created a second variable with the entire dictionary-list-of-dictionary as a string, using double quotes. I attempted to use the variable in a task that calls the command and passes the arguments. The ansible-playbook could not process the command although the variable did seem to be substituted correctly, meaning my string did show up in the debug output.
I then attempted to combine multiple variables by creating a dictionary, assigning the dictionary as a single element list, and placed that inside another dictionary. That renders properly but the command then fails, as the command needs to have the double quotes around it’s values, which are missing when I create the ansible dictionary.

To get the playbook working, I just put the command in a shell script and called the shell script. I would much prefer calling the command in ansible and providing the arguments from variables if the quoting problem can be solved. I was wondering if anyone has any quote-filtering magic that can be shared.

2

Hey @rustydraper ! Welcome to The Forum.

You could make it a lot easier for us to help you if you show us what you did exactly rather than expect us to correctly recreate the problem from a description. We can’t offer a solution until we can reproduce the problem.

Here’s how to properly enter YAML into forum posts:

```yaml
- name: Task-name
  ansible.builtin.command: mycommand --myarg1=myargvalue --myarg2=‘{“mytags”: [{“myint1”: 12345, “mystr1”: “fubarbaz”}]}’
[etc.]
```

The above doesn’t count; it’s just a copy-n-paste (with some guesswork) of what you started with. But, please, don’t expect us to guess correctly; show us. We really do want to help.

3

A common issue is that the short form of calling the command and shell modules introduces an additional layer of parsing. It is significantly more robust to use the cmd argument, e.g instead of:

- command: echo hello world

you should write

- command:
    cmd: echo hello world

It’s slightly more typing, but avoids quite a bit of weirdness.

2 Likes
4

A minimal example playbook

---
- hosts: localhost
  become: false
  gather_facts: false

  tasks:

    - name: Pass arguments
      command:
        cmd: |
          echo \
          --myarg1=myargvalue \
          --myarg2='{"mytags": [{"myint1": 12345, "mystr1": "fubarbaz"}]}'
      register: result

    - name: Show arguments
      debug:
        msg: "{{ result }}"

will result into the expected execution and an output of

TASK [Show arguments] ***********************************************
ok: [localhost] =>
  msg:
    changed: true
    cmd:
    - echo
    - |2-

      --myarg1=myargvalue
    - |2-

      --myarg2={"mytags": [{"myint1": 12345, "mystr1": "fubarbaz"}]}
    delta: '0:00:00.004918'
    end: '2025-12-31 10:30:00.223432'
    failed: false
    msg: ''
    rc: 0
    start: '2025-12-31 10:30:00.218514'
    stderr: ''
    stderr_lines: []
    stdout: |2-

      --myarg1=myargvalue
      --myarg2={"mytags": [{"myint1": 12345, "mystr1": "fubarbaz"}]}
    stdout_lines:
    - ''
    - '--myarg1=myargvalue '
    - '--myarg2={"mytags": [{"myint1": 12345, "mystr1": "fubarbaz"}]}'