I'm trying to use the handleize filter from liquid in Jekyll, but it seems to pass the text straight through without doing the filtering.
I have a include file (eg, _include/example.html) and inside there is
{{ 'Test Text' | handleize }}
From reading some documentation I expect the following text to be generated
test-text
but instead I get
Test Text
Is there something obvious I'm missing here? I'm using Jekyll 1.4.3 and liquid 2.5.5.
An interesting point is that there doesn't seem to be the handle filter when I look in the Liquid API docs, but confusingly the Jekyll docs points to the doc link given above.
Instead of rolling your own version of this filter, from Jekyll version 2.4.0 onward you can use the built-in slugify filter, which basically does what handleize did.
Handelize isn't implemented in Jekyll. See this issue here for an explanation (has to do with Jekyll-Liquid vs. Shopify-Liquid).
There are a couple Jekyll-Plugins you could use to add this functionality in. Or you could use the Downcase and Replace filters to do the job manually as needed:
{{ 'Test Text' | downcase | replace: ' ', '-' }}
Related
I am using Salt with jinja2 "regex_search" and I try to extract some digits (release version) from the archive file name. Then use the value to create a symlink, that contains it. I've tried different combinations using "list", "join" and other filters to get rid of this Unicode char, but without success.
Example:
"release_info" variable gets value "release-name-0.2345.577_20190101_1030.tar.gz" and I need to get only digits between the dots.
Here is the corresponding part of the sls file:
symlink to current release {{ release_info }}:
file.symlink:
- name: /home/{{ component.software['component_name'] }}/latest
- target: /home/{{ component.software['component_name'] }}/{{ release_info |regex_search('(\d+\.\d+\.\d+)') }}
- user: support
- group: support`enter code here`
The expected result is "/home/support/0.2345.577", but I have "/home/support/(u'0.2345.577',)"
If I try to pipe "yaml" or "json" filter like:
{{ release_info |regex_search('(\d+\.\d+\.\d+)') | yaml }}
I've got:
/home/support/[0.2345.577]
which is not what I am looking for.
PS
I've got it, but seems to me as not a got approach. Just workaround.
{{ release_info |regex_search('(\d+\.\d+\.\d+)') |yaml |replace('[','') |replace(']','') }}
Hello Todor and Welcome to Stack Overflow!
I have tried the example that you have posted and here is how to achieve what you want
Note: I have changed the regex pattern a little in order to support any other possibilities that could have more digits e.g 0.1.2.3.4 and so on, but of course you can use your pattern as long as it works for you as expected.
Solution 1:
{{ release_info | regex_search("(\d(\.\d+){1,})") | first }}
The result before using first:
('0.2345.577', '.577')
The result after using first:
0.2345.577
Solution 2:
{{ release_info | regex_search("(\d\.\d+\.\d+)") | first }}
The result before using first:
('0.2345.577',)
The result after using first:
0.2345.577
first is a built-in filter in jinja that can return the first item in a sequence. you can check List of built-in filters for more information about the other filters
I am trying to use a value defined inside a pillar, as a variable to be setup at deployment time, e.g :
cat pillar/passwd.sls
server_gpg: 'gpgPassword'
I'd like to use the value of "server_gpg" variable inside a script, I tried this but this does work :
/usr/bin/gpg --yes --passphrase '{{ pillar['gpgPassword'] }}' [...]
I am sure this is a noob (which is what I am) question, but I could not find a working tips within the Salt / Jinja docs.
Thanks
OK, my bad, after some more research in the saltstack i found out that I was just missing a :
- template: jinja
definition in my state declaration.
I need to read an ip line from a dynamic generated json file and add it to a configuration file on the server.
At Ansible home page i found two modules which would help:
- lookup module
- fileinline module
The lookup examples however show looking up for the whole contents of a file using this phrase "{{ lookup('file', '/etc/foo.txt') }}"
How could i filter the result into reading a single line?
Does anybody know a good way to achieve this ?
You probably do want a special key from a JSON dict I guess? If it's just a random line which can not be accessed inside the JSON struct it will be hard. You would need to grep out the line in a separate task.
But let's assume you want a special value from a dict, then you can convert the JSON to an object with the from_json filter:
{{ lookup('file', '/etc/foo.txt') | from_json }}
Now if you want the value of bar from the contained data structure, something like this should work:
{{ (lookup('file', '/etc/foo.txt') | from_json).get('bar') }}
Is there any existing method of automatically compiling and running code highlights in jekyll pages, inserting the output into the target HTML?
I've made such a thing. Code repository is here : https://github.com/djacquel/JekyllDoc
The result is here : http://jekyll.pygmeeweb.com/tests/
How it works
A rake task generates a new page from a data file which contains code snipped
Data are like
snippet: '{% assign my_array = "one|two" | split: "|" %}{{ my_array | push: "three" }}'
This snippet is inserted in a template used to create a new page.
Then a Jekyll build will interpret the code in this new page.
Not so clear isn't it ?? Just ask I'll answer. New year lag...
I have looked at how to embed HTML syntax in JavaScript string from HTML syntax highlighting in javascript strings in vim.
However, when I use CoffeeScript I cannot get the same thing working by editing coffee.vim syntax file in a similar way. I got recursive errors which said including html.vim make it too nested.
I have some HTML template in CoffeeScript like the following::
angular.module('m', [])
.directive(
'myDirective'
[
->
template: """
<div>
<div>This is <b>bold</b> text</div>
<div><i>This should be italic.</i></div>
</div>
"""
]
)
How do I get the template HTML syntax in CoffeeScript string properly highlighted in VIM?
I would proceed as follows:
Find out the syntax groups that should be highlighted as pure html would be. Add html syntax highlighting to these groups.
To find the valid syntax group under the cursor you can follow the instructions here.
In your example the syntax group of interest is coffeeHereDoc.
To add html highlighting to this group execute the following commands
unlet b:current_syntax
syntax include #HTML syntax/html.vim
syn region HtmlEmbeddedInCoffeeScript start="" end=""
\ contains=#HTML containedin=coffeeHereDoc
Since vim complains about recursion if you add these lines to coffee.vim i would go with an autocommand:
function! Coffee_syntax()
if !empty(b:current_syntax)
unlet b:current_syntax
endif
syn include #HTML syntax/html.vim
syn region HtmlEmbeddedInCoffeeScript start="" end="" contains=#HTML
\ containedin=coffeeHereDoc
endfunction
autocmd BufEnter *.coffee call Coffee_syntax()
I was also running into various issues while trying to get this to work. After some experimentation, here's what I came up with. Just create .vim/after/syntax/coffee.vim with the following contents:
unlet b:current_syntax
syntax include #HTML $VIMRUNTIME/syntax/html.vim
syntax region coffeeHtmlString matchgroup=coffeeHeredoc
\ start=+'''\\(\\_\\s*<\\w\\)\\#=+ end=+\\(\\w>\\_\\s*\\)\\#<='''+
\ contains=#HTML
syn sync minlines=300
The unlet b:current_syntax line disables the current syntax matching and lets the HTML syntax definition take over for matching regions.
Using an absolute path for the html.vim inclusion avoids the recursion problem (described more below).
The region definition matches heredoc strings that look like they contain HTML. Specifically, the start pattern looks for three single quotes followed by something that looks like the beginning of an HTML tag (there can be whitespace between the two), and the end pattern looks for the end of an HTML tag followed by three single quotes. Heredoc strings that don't look like they contain HTML are still matched using the coffeeHeredoc pattern. This works because this syntax file is being loaded after the syntax definitions from the coffeescript plugin, so we get a chance to make the more specific match (a heredoc containing HTML) before the more general match (the coffeeHeredoc region) happens.
The syn sync minlines=300 widens the matching region. My embedded HTML strings sometimes stretched over 50 lines, and Vim's syntax highlighter would get confused about how the string should be highlighted. For complete surety you could use syn sync fromstart, but for large files this could theoretically be slow (I didn't try it).
The recursion problem originally experienced by #heartbreaker was caused by the html.vim script that comes with the vim-coffeescript plugin (I'm assuming that was being used). That plugin's html.vim file includes the its coffee.vim syntax file to add coffeescript highlighting to HTML files. Using a relative syntax include, a la
syntax include #HTML syntax/html.vim
you get all the syntax/html.vim files in VIM's runtime path, including the one from the coffeescript plugin (which includes coffee.vim, hence the recursion). Using an absolute path will restrict you to only getting the particular syntax file you specify, but this seems like a reasonable tradeoff since the HTML one would embed in a coffeescript string is likely fairly simple.