To me it looks like you're getting the same as me (I had to zoom in my
screen to be sure :-) ) - contents of templated json contains a single
backslash after the drive letter (which is not valid)
These Json files might be read by applications that are not able to parse
"forward-slashed" paths, so although Powershell would be fine with that
format, it's not always an option to use them in json files (so essentially
this is not as much a problem with the Powershell-based Ansible modules as
the fact that its hard to inject valid json into json files).
I'll look into the win_* filter - I haven't spent much time with those (I
kinda wish they were a bit better documented)
I'll keep this thread updated with my findings.
On Monday, May 15, 2017 at 9:38:10 AM UTC+2, J Hawkesworth wrote:
>
> 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/b96b5f77-e112-483b-bd91-1a29cc788d1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
