I must be missing something here, YAML 1.2 documentation doesn't seem to mention this so I figured I'd ask here.
Consider the below snippet from my YAML file
- match: '(dns_[a-z_]+|tls_(cert[a-z_]+)|tls.subject)'
How do I ensure that the period is matched literally? I've tried all sorts of escapes and even tried to specify the hex value but, it's never seen by YAML and thus isn't matching tls.subject, ever. What am I missing here?
Related
Intellij keeps formatting my spotbugs.yml file incorrectly, and so breaking the github action.
I cannot figure out why it's doing this:
It was working fine last week, I haven't made any changes to the formatting config, but now, every time I change focus from the file Intellij auto-formats like this, then saves it. How can I fix it?
The thing I don't get is what it's formatting to appears to be invalid yaml, right?
YAML has a syntax that makes it incompatible with indentation that is not 2 spaces. With 4 spaces, you have:
droggel:
jug:
- sequence item: with indentation
this line: isn't aligned to four spaces
nor are further indented lines:
if you indent relative four spaces
spam:
- same: problem
without: indenting the sequence item
This makes it hard for code formatters to get it right. Proper alignment would mean:
droggel:
jug:
- three spaces after the sequence item indicator.
that's horrible, nobody does that.
spam:
- alternatively this.
nobody does this either and it breaks
- - with nested sequences
I assume some bug in IntelliJ causes the formatter to be confused because of this. Generally it would be better to just use 2 space indentation which seems far more natural due to the problems described above. That should avoid confusing the formatter.
I saw a YAML file that includes some signs like $, ^. For $, I think it tries to get value from a JSON file. But for ^, I'm not sure about that.
I tried to search for the YAML syntax but cannot find the usage of those signs.
Could anyone point out where that usage from? Thanks a lot!
examples:
json: $.A.Documents[*]
input: ^.B.ID
YAML doesn't assign any special meaning to those characters. As far as YAML is concerned, they are simply part of the content.
Of course, the software loading that YAML can do anything with the loaded data – including inspecting the loaded scalars for $ and ^ and implementing some action on them.
While someone might be able to correctly guess which software expects a YAML file like the one you show, it would be vastly easier for you to check the context in which you found that YAML file. This should lead you to the information you seek – i.e., for which software that YAML file has been written. That software's documentation will then describe how those characters are processed.
We're using Freemarker version 2.3.16, and I've just tracked down a weird bug in one of our apps. It came down to there now being hyphens in some of our product code strings. The codes are used to pull hashes of localized text from the global scope using .vars.
Reducing the issue brought me to an example that anyone can try:
${.vars["foo-bar"]} in a template outputs 0
${.vars["foo+bar"]} outputs nullnull
${.vars["foobar"]} correctly triggers an InvalidReferenceException
All three should trigger exceptions. Instead, it appears the .vars parameter string is being evaluated! :-(
http://freemarker.sourceforge.net/docs/app_faq.html#faq_strange_variable_name implies this should work.
I saw mention of a similar issue a few weeks ago on the Freemarker mailing list, and it was suggested to prefix the parameter string with "#". That might work with other hashes, but it does NOT work with .vars. I just took a working example (.vars["resources_title"]) and changing it made it throw an InvalidReferenceException (.vars["#resources_title"]). I also tried it on the hyphenated reference, and it also threw the exception.
Upgrading to 2.3.18 did not seem to make a difference.
Sorry for the delay. After some good mailing-list help on places to put breakpoints, here's I wrote back to the list on June 10th:
Short story: It's not a Freemarker issue. Rather the Struts team chose to hard-wire Freemarker to treat .vars names as OGNL expressions, and there seems no way to tell OGNL to not parse them. So under Struts, "-" and "+" (and possibly other characters) cannot appear in .vars names.
Long story...
freemarker.core.BuiltinVariable (line 192) is where Freemarker starts to process .vars expressions
freemarker.core.Environment (line 1088) hands control over to the "rootDataModel" which the Struts team hard-wired to be an instance of org.apache.struts2.views.freemarker.ScopesHashModel
line 70 of that class (using version 2.1.8.1 of Struts) calls "stack.findValue"; "stack" has been wired to be an instance of com.opensymphony.xwork2.ognl.OgnlValueStack
at line 236 this class in turn asks an instance of OgnlUtil to find the object, and that's where the name is assumed to be an OGNL expression and is parsed, turning "foo-bar" into ( foo - bar )
At no point along the way does there seem to be a choice to NOT treat the .vars name as an expression (a comment in FreemarkerResult hints at the possibility, but the code doesn't follow through). In theory I could have my implementation of FreemarkerManager create a variant of ScopesHashModel, but that would take a lot of work to change all the associated classes with it.
(Nor does there seem to be a way to escape "-" characters in OGNL expressions. Seems there was discussion 5-6 years ago to do this, but.... .vars( "foo\\-bar" ) fails on finding "-" after "\", so presumably "-" isn't escapable?)
:-(
I'm not clear what the use-case is for treating .vars names as expressions... but I don't think Struts is going to change, now. Rather than override a half dozen Struts classes, I instead changed the code that loads our ResourceBundles into the value stack: it now changes the names to replace "-" and "_", and likewise my .vars names are changed the same way in the template and... tada. It works. Woo.
Works for me. And like already mentioned on the freemarker-user mailing list: maybe you use a strange data model, or even a fancy ObjectWrapper. But a discussion like this is probably better suited for the freemarker-user mailing list...
It works if it added with escape foo\-bar.
"Only single backslash"
Since freemarker version 2.3.22 is it possible to use dot (.), minus sign (-) or colon (:) in a variable name (details here).
In my case, it fails if I tried to use with freemarker 2.3.21 variables like :
api["x-link"]
If I change freemarker to version 2.3.22 it works.
(Using Ruby 1.8)
I only have a brief understanding of encoding and such...but what I want to know is, in any given script handling any given text-file, is there some universal library or call I need to make to turn non-standard characters into their nearest printable equivalent. I realize there's no "all-in-one" fix, but this is for a English (U.S. gov't) text file, and so I'm wondering if there's something that mitigates what must be a relatively common issue in English text formatting.
For example, in a text file, I have an entry like this:
0-823
That hyphen is just literally a hyphen as I've typed it out. In the file though, it's something that looks like a hyphen (an n-dash?) but when copy and pasting it...for example, into this browser text box, it doesn't show up.
Printing it out via a Ruby script gets this:
08�23
How do I get my script to resolve it into a dash. Or something other than a gremlin?
It's very common to run into hyphen-like characters and dashes, especially in the output of word-processors. Converting them isn't too hard if you know what the byte is that represents the character, but gets to be a pain when you get a document with several different ones. It gets worse as you throw other accented characters into the mix.
Ruby 1.8 doesn't support multibyte and Unicode character sets as well as 1.9+, but you can work around that somewhat by using the Iconv library.
Iconv lets you convert between various character-sets, such as US-ASCII, ISO-8859-1 and WIN-1252. It's smarter than a regex, because it knows how to convert from accented characters, to similarly looking characters, or ignore them if nothing similar exists, allowing your transliteration to degrade gracefully.
I have some example code in an answer to a related question. Also read James Grey's article linked in the answer. It explains the problem and ways to fix it, ending up with recommending Iconv too.
You could whitelist with gsub:
string.gsub(/[^a-zA-Z0-9]/)
Without knowing more information, I can't build the perfect regex for you, but the general idea is to replace anything that's not what you're expecting (anything not a letter or number or expected symbols).
It seems like LDAP requires strings with non-ASCII characters to be Base64 encoded. The way to tell it that a string is to be parsed as a base64 encoded string is to add an extra colon to the attribute name such that "cn: name" becomes "cn:: name" (according to this site).
Now, my question is: How do I tell Ruby LDAP to do this? I could not find that the documentation mentions anything about it, but perhaps it is supported.
What about the other LDAP libraries, such as Net::LDAP? Do they support operations with non-ASCII characters?
Update:
The test suite for Ruby/LDAP (0.9.7, ruby v. 1.8.6) includes tests for adding entries with foreign characters in the LDAP. They set $KCODE="UTF8". However, this seems to have no effect in my setup.
non-ASCII characters are allowed for attributes as long as there is only ASCII-characters in the dn, so I currently use a workaround with an ASCII-only uid. However, this does not feel optimal.
I solved the problem by switching to Net::LDAP (which by the way feels much nicer to use). This required me to upgrade to ruby 1.8.7, though.