variables with 'dashes' in them

[Romeo Theriault]

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,

--

Romeo

[Michael DeHaan]

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?

> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ansible-proje...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Romeo Theriault]

On Thu, Feb 14, 2013 at 5:34 PM, Michael DeHaan <michael...@gmail.com> wrote:

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,

--

Romeo