# results from a multi-item Ansible task lacks the 'stdout\_lines' attribute in the returned data structure **URL:** \ **Category:** Ansible Project\ **Created:** [February 20, 2014, 9:48pm UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612 "2014-02-20T21:48:20Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Roman\_Revyakin](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@Roman\_Revyakin](https://forum.ansible.com/u/Roman_Revyakin)\ **Post date:** [February 20, 2014, 9:48pm UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/1 "2014-02-20T21:48:20Z")
Hi Michael, One of the pain points for us often times is the Ansible lack of the human-readable representability of the output of the task that has been run. A workaround up to now has been to use the `debug: var=output.stdout_lines` which while not perfect is at least more bearable in terms that one does not have to unwrap the ‘\n’ into the new lines in his mind while reading the output: - name: post-deployment tasks executed local\_action: shell cd tasks; ls when: cf\_post\_deployment\_tasks is defined register: post tags: - post-deploy - debug: var=post.stdout\_lines tags: - post-deploy TASK: [debug var=post.stdout\_lines] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ok: [localhost] =\> { “item”: “”, “post.stdout\_lines”: [ “cf\_app\_remap.yml”, “cf\_deployment.yml”, “concat\_files.yml”, “npm\_install.yml” ] } However, once a task is a multi-item one, the returned data structure lacks the `stdout_lines` attribute: - name: post-deployment tasks executed local\_action: shell {{ item }} with\_items: cf\_post\_deployment\_tasks when: cf\_post\_deployment\_tasks is defined register: post tags: - cf - post-deploy - debug: var=post tags: - post-deploy TASK: [debug var=post] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ok: [localhost] =\> { “item”: “”, “post”: { “changed”: true, “cmd”: "cd tasks; ls ", “delta”: “0:00:00.004343”, “end”: “2014-02-21 08:31:01.088304”, “invocation”: { “module\_args”: “cd tasks; ls”, “module\_name”: “shell” }, “item”: “”, “rc”: 0, “start”: “2014-02-21 08:31:01.083961”, “stderr”: “”, “stdout”: “cf\_app\_remap.yml\ncf\_deployment.yml\nconcat\_files.yml\nnpm\_install.yml”, “stdout\_lines”: [ “cf\_app\_remap.yml”, “cf\_deployment.yml”, “concat\_files.yml”, “npm\_install.yml” ] } } Could you tell if it’s something you would consider fixing if I create an issue on github? Thanks, With kind regards, Roman ---
**Author:** ![Roman\_Revyakin](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@Roman\_Revyakin](https://forum.ansible.com/u/Roman_Revyakin)\ **Post date:** [February 20, 2014, 9:51pm UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/2 "2014-02-20T21:51:26Z")
Sorry, posted wrong output for the multi-item task (too early in the morning I guess :-). Here’s the evidence the multi-item ‘results’ return data structure lacks the ‘stdout\_lines’ attribute for the individual items: TASK: [debug var=post] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ok: [localhost] =\> { “item”: “”, “post”: { “changed”: true, “msg”: “All items completed”, “results”: [ { “changed”: true, “cmd”: "cd tasks; ls ", “delta”: “0:00:00.006166”, “end”: “2014-02-21 08:30:32.003038”, “invocation”: { “module\_args”: “cd tasks; ls”, “module\_name”: “shell” }, “item”: “cd tasks; ls”, “rc”: 0, “start”: “2014-02-21 08:30:31.996872”, “stderr”: “”, “stdout”: “cf\_app\_remap.yml\ncf\_deployment.yml\nconcat\_files.yml\nnpm\_install.yml” } ] } } ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [February 21, 2014, 1:10am UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/3 "2014-02-21T01:10:11Z")
I’m not sure. If the output is many pages long, that would be a lot of redundant data. That being said, that is true of the original. ---
**Author:** ![Roman\_Revyakin](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@Roman\_Revyakin](https://forum.ansible.com/u/Roman_Revyakin)\ **Post date:** [February 21, 2014, 1:15am UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/4 "2014-02-21T01:15:31Z")
There could be a lot of redundant data if the output is many pages long even in the case of a one-item task - in the current implementation. So I do not take your point on that one. An alternative solution would be, of course to make Ansible to format the output in a human readable way on the user’s request. Then there would be no need in duplicating `stdout` with `stdout_lines` at all. ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [February 21, 2014, 1:24am UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/5 "2014-02-21T01:24:20Z")
you have |pprint and |to\_nice\_json filters to make the output 'human friendly. I use this on debug: all the time. ---
**Author:** ![Roman\_Revyakin](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@Roman\_Revyakin](https://forum.ansible.com/u/Roman_Revyakin)\ **Post date:** [February 21, 2014, 1:42am UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/6 "2014-02-21T01:42:51Z")
Hey Brian, Could you please provide an example (say based on the tasks I’ve posted earlier in my post), as I could not make use of those filters in ‘debug’ task. Thank you! ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [February 21, 2014, 1:47am UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/7 "2014-02-21T01:47:05Z")
its very simple: - debug: msg={{post|pprint}} ---
**Author:** ![Roman\_Revyakin](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@Roman\_Revyakin](https://forum.ansible.com/u/Roman_Revyakin)\ **Post date:** [February 21, 2014, 4:19am UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/8 "2014-02-21T04:19:30Z")
Hey Brian, I do not think that the pprint filter on a multi-item task make the output any readable. Based on my previous example, if I do - name: post-deployment tasks executed local\_action: shell {{ item }} with\_items: cf\_post\_deployment\_tasks when: cf\_post\_deployment\_tasks is defined register: post tags: - cf - post-deploy - debug: msg=“{{ post | pprint }}” when: post is defined tags: - cf - post-deploy and cf\_post\_deployment\_tasks is a list of the following items: cf\_post\_deployment\_tasks: - cd tasks; ls - echo -e “blah blah blah\nsecond line” I get: TASK: [debug msg=“Undefined”] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ok: [localhost] =\> { “item”: “”, “msg”: “{‘changed’: True,\n ‘msg’: ‘All items completed’,\n ‘results’: [{u’changed’: True,\n u’cmd’: u’cd tasks; ls ‘,\n u’delta’: u’0:00:00.004785’,\n u’end’: u’2014-02-21 15:17:40.739631’,\n ‘invocation’: {‘module\_args’: u’cd tasks; ls’,\n ‘module\_name’: ‘shell’},\n ‘item’: ‘cd tasks; ls’,\n u’rc’: 0,\n u’start’: u’2014-02-21 15:17:40.734846’,\n u’stderr’: u’‘,\n u’stdout’: u’cf\_app\_remap.yml\ncf\_app\_route.yml\ncf\_deployment.yml\nconcat\_files.yml\nnpm\_install.yml’},\n {u’changed’: True,\n u’cmd’: u’echo -e blah” } If I use the item-by-item approach to output, that is - debug: msg=“{{ item | pprint }}” when: post is defined with\_items: post.results tags: - cf - post-deploy the output is lengthier and still a mess: TASK: [debug msg=“‘’”] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* ok: [localhost] =\> (item={‘item’: ‘cd tasks; ls’, u’delta’: u’0:00:00.004356’, u’cmd’: u’cd tasks; ls ‘, u’end’: u’2014-02-21 15:18:59.617802’, u’stderr’: u’‘, u’stdout’: u’cf\_app\_remap.yml\ncf\_app\_route.yml\ncf\_deployment.yml\nconcat\_files.yml\nnpm\_install.yml’, ‘invocation’: {‘module\_name’: ‘shell’, ‘module\_args’: u’cd tasks; ls’}, u’changed’: True, u’rc’: 0, u’start’: u’2014-02-21 15:18:59.613446’}) =\> { “item”: { “changed”: true, “cmd”: "cd tasks; ls ", “delta”: “0:00:00.004356”, “end”: “2014-02-21 15:18:59.617802”, “invocation”: { “module\_args”: “cd tasks; ls”, “module\_name”: “shell” }, “item”: “cd tasks; ls”, “rc”: 0, “start”: “2014-02-21 15:18:59.613446”, “stderr”: “”, “stdout”: “cf\_app\_remap.yml\ncf\_app\_route.yml\ncf\_deployment.yml\nconcat\_files.yml\nnpm\_install.yml” }, “msg”: “{u’changed’: True,\n u’cmd’: u’cd tasks; ls ‘,\n u’delta’: u’0:00:00.004356’,\n u’end’: u’2014-02-21 15:18:59.617802’,\n ‘invocation’: {‘module\_args’: u’cd tasks; ls’, ‘module\_name’: ‘shell’},\n ‘item’: ‘cd tasks; ls’,\n u’rc’: 0,\n u’start’: u’2014-02-21 15:18:59.613446’,\n u’stderr’: u’‘,\n u’stdout’: u’cf\_app\_remap.yml\ncf\_app\_route.yml\ncf\_deployment.yml\nconcat\_files.yml\nnpm\_install.yml’}” } ok: [localhost] =\> (item={‘item’: ‘echo -e “blah blah blah\nsecond line”’, u’delta’: u’0:00:00.003149’, u’cmd’: u’echo -e “blah blah blah\nsecond line” ‘, u’end’: u’2014-02-21 15:18:59.703624’, u’stderr’: u’‘, u’stdout’: u’-e blah blah blah\nsecond line’, ‘invocation’: {‘module\_name’: ‘shell’, ‘module\_args’: u’echo -e “blah blah blah\nsecond line”‘}, u’changed’: True, u’rc’: 0, u’start’: u’2014-02-21 15:18:59.700475’}) =\> { “item”: { “changed”: true, “cmd”: "echo -e "blah blah blah\nsecond line" ", “delta”: “0:00:00.003149”, “end”: “2014-02-21 15:18:59.703624”, “invocation”: { “module\_args”: “echo -e "blah blah blah\nsecond line"”, “module\_name”: “shell” }, “item”: “echo -e "blah blah blah\nsecond line"”, “rc”: 0, “start”: “2014-02-21 15:18:59.700475”, “stderr”: “”, “stdout”: “-e blah blah blah\nsecond line” }, “msg”: “{u’changed’: True,\n u’cmd’: u’echo -e blah” } ---
**Author:** ![Florian\_Gysin](https://avatars.discourse-cdn.com/v4/letter/f/45deac/32.png) [@Florian\_Gysin](https://forum.ansible.com/u/Florian_Gysin)\ **Post date:** [January 8, 2015, 1:08pm UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/9 "2015-01-08T13:08:52Z")
**+ 1 for Romans issue.** I also find the output of debug to be highly irritating and the missing stdout\_lines attribute on multi-item tasks void the only possible way of getting human readable output. ---
**Author:** ![Roman\_Revyakin](https://avatars.discourse-cdn.com/v4/letter/r/dc4da7/32.png) [@Roman\_Revyakin](https://forum.ansible.com/u/Roman_Revyakin)\ **Post date:** [January 8, 2015, 8:50pm UTC](https://forum.ansible.com/t/results-from-a-multi-item-ansible-task-lacks-the-stdout-lines-attribute-in-the-returned-data-structure/14612/10 "2015-01-08T20:50:44Z")
Hey Florian, Thanks for your support on this issue. I have meanwhile discovered that there is an alternative way to handle the output and format it to your liking by using callback plugins, here’s a couple of good examples on how to use this feature: [http://blog.cliffano.com/2014/04/06/human-readable-ansible-playbook-log-output-using-callback-plugin](http://blog.cliffano.com/2014/04/06/human-readable-ansible-playbook-log-output-using-callback-plugin) [http://jpmens.net/2012/09/11/watching-ansible-at-work-callbacks](http://jpmens.net/2012/09/11/watching-ansible-at-work-callbacks) It obviously has some drawbacks - such as one would need to reimplement the highlighting etc, but it’s at least something to workaround the issue. Hope that helps. Best regards, Roman