I'm not seeing the behaviour you describe - maybe my playbook isn't doing
the same things as yours though?
# playbook:
$ cat trondpath.yml
---
- name: test trond observed strange path behaviour
hosts: TENSY
vars:
logfiles_path: "F:\\Logs"
connection: winrm
gather_facts: false
tasks:
- name: create json file from template
win_template:
src: template.json
dest: templated.json
# template file:
$ cat template.json
{
"FilePath":"{{ logfiles_path }}\\*",
"Stuff": otherstuff
}
contents of templated.json:
{
"FilePath":"F:\Logs\\*",
"Stuff": otherstuff
}
I'm using ansible 2.3 (Win 10 WSL / Ubuntu )
Dag is right though we should document this - I've put it on my list.
Better still would be to document and make some kind of automated test like
the integration tests for modules. There are probably quite a few possible
combinations to work through - absolute and relative paths, paths to files,
paths to dirs and then all the places you can define them - hostvars, group
vars, included vars, in-playbook vars, hardcoded in playbooks, hardcoded in
templates, and inside {{ }}
For info there are filters for windows style paths.
See http://docs.ansible.com/ansible/playbooks_filters.html
win_basename, win_splitdrive and win_dirname are the windows-specific ones.
Another trick you can use is to use unix style path separators - powershell
is *usually* ok with this but obviously it depends on what is happening in
your powershell code - if you pass a path to a native windows binary in
your powershell (or ansible module code) obviously this isn't going to work.
Hope this helps,
Jon
On Tuesday, May 9, 2017 at 1:30:11 PM UTC+1, Dag Wieers wrote:
>
> On Tue, 9 May 2017, Trond Hindenes wrote:
>
> > Hope someone can help me shed some light on this one:
> >
> > Since Ansible is python-based, us Windows dudes generally have to stick
> an
> > extra backslash anywhere we're manipulating Windows paths. However, in
> some
> > cases this causes unexpected behavior. In my current case, I need to
> inject
> > a file path into a json file on a Windows box. This path is defined as
> such
> > in an Ansible var:
> > logfiles_path: "F:\\Logs"
> >
> > In my template json file I add to this path, using the following:
> >
> > "FilePath":"{{ logfiles_path }}\\*",
> >
> > The goal is to populate the target json with
> > "F:\\Logs\\*"
> >
> > However, since Ansible kicks in the resulting file contains:
> > "F:\Logfiles\\*"
> >
> > In other words, Ansible "normalises" the part of the path that comes
> from a
> > variable, but not the part "outside" of the variable.
> >
> > I'm not sure what the best way to solve this is - it would be great to
> have
> > some builtin filters that would do "json normalization" of a string or
> > something. How are people solving this?
>
> I stick to using single backslashes (and not quotes) in YAML, or single
> quotes if you have to. And single quotes everywhere else. I never had the
> need to use double-backslashes.
>
> I remember one issues (with YAML?), which is when using a trailing
> backslash. So I taught myself not to do this for Windows paths :-)
>
> It would be nice to document these best-practices as part of the Ansible
> Windows documentation once we have determined what's best.
>
> --
> Dag
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/d1659263-a5d8-4ba3-b413-512411459a55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
