# variables with 'dashes' in them

**URL:** <https://forum.ansible.com/t/variables-with-dashes-in-them/12358>\
**Category:** Ansible Project\
**Created:** [February 15, 2013, 12:34am UTC](https://forum.ansible.com/t/variables-with-dashes-in-them/12358 "2013-02-15T00:34:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\
**Post date:** [February 15, 2013, 12:34am UTC](https://forum.ansible.com/t/variables-with-dashes-in-them/12358/1 "2013-02-15T00:34:59Z")

</div>

I’m noticing that variables names (or registers in ansible) that have ‘-’ (dashes) in their names fail to expand when later called. Here’s a simple example playbook that demonstrates:

- name: run1  
command: whoami  
register: who

- name: run2  
command: whoami  
register: who-who

- name: show  
debug: msg=“run1 output= ${who.stdout} run2 output= ${who-who.stdout}”

The output when run with verbose is:

TASK: [show] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
ok: [127.0.0.1] =\> {“msg”: “run1 output= romeotheriault run2 output= ${who-who.stdout}”}

(The same holds true if it’s a variable like ${login.set-cookie})

This is causing me a bit of an issue with the URI module I’m developing, since some of the returned headers have dashes in them. (e.g. set-cookie, content-type).

Before I dig into this too much, is this an issue that can be “fixed” or is this something I’ll need to get my module to work-around, for example by replacing all “dashes” with “underscores” or something like that?

Thanks,

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [February 15, 2013, 3:34am UTC](https://forum.ansible.com/t/variables-with-dashes-in-them/12358/2 "2013-02-15T03:34:03Z")

</div>

We can probably easily fix the template evaluation, though it's  
probably done that way as a variable named "foo-bar" is not a valid  
Python variable and can't be accessed directly in Jinja2 either.

It could be accessed through hostvars (and can, too, in your case, I imagine).

Generally dash isn't good for variables in most programming languages  
either, so maybe registering to it should really be the core error.

I generally think maybe you might want to transmogrify the headers you  
get back so they use underscores and not dashes?  
Maybe?

---

<div class="post-metadata">

**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\
**Post date:** [February 15, 2013, 6:44am UTC](https://forum.ansible.com/t/variables-with-dashes-in-them/12358/3 "2013-02-15T06:44:18Z")

</div>

> We can probably easily fix the template evaluation, though it's  
> probably done that way as a variable named "foo-bar" is not a valid  
> Python variable and can't be accessed directly in Jinja2 either.

If it's going to work in some places and not others, I'd say it's probably  
better to just keep things consistent and "not allow it".

> It could be accessed through hostvars (and can, too, in your case, I  
> imagine).

> Generally dash isn't good for variables in most programming languages  
> either, so maybe registering to it should really be the core error.

Yeah, I think something along those lines would be good. Some kind of  
error/warnings certainly would have helped me save some time  
troubleshooting it.

> I generally think maybe you might want to transmogrify the headers you  
> get back so they use underscores and not dashes?  
> Maybe?

I'm perfectly fine with doing this. This is how I'll proceed.

Thanks,