You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Periods (.) are x2E which is well within the range of [x20-x7E] given in c-printable and is not one of the chars excluded from ns-char via b-char, c-byte-order-mark, or s-white.
I don’t see any way to configure yamllint to not balk on this, or at least reduce this to a warning (other than comment-disabling). I can definitely see limiting anchor names to alphanumeric characters to be desired for many use cases (for compatibility/interoperability), but the spec allows for a wider range of characters used here, so this should probably reasonably be a configuration toggle.
%YAML 1.2
---
test:
- &test-with-.period "This is a test of an anchor with a period (`.`)."test2:
- *test-with-.period
...
> yamllint --version
yamllint 1.35.1
> yamllint test.yaml
test.yaml
4:16 error syntax error: expected alphabetic or numeric character, but found '.' (syntax)
The text was updated successfully, but these errors were encountered:
I just want to comment that the underlying issue is in pyyaml.
It is more restrictive than the YAML spec regarding what is allowed in anchor names. yaml/pyyaml#373 yaml/pyyaml#389
The current pyyaml maintainer wants to keep it that way. The same is true for libyaml, btw.
Not sure if yamllint can work around that syntax error from pyyaml.
yamllint
complains about the use of periods (.
) in anchor names. As far as I can discern,ns-anchor-char
allows allns-char
s except forc-flow-indicator
s (,[]{}
).Periods (
.
) arex2E
which is well within the range of[x20-x7E]
given inc-printable
and is not one of the chars excluded fromns-char
viab-char
,c-byte-order-mark
, ors-white
.I don’t see any way to configure
yamllint
to not balk on this, or at least reduce this to a warning (other than comment-disabling). I can definitely see limiting anchor names to alphanumeric characters to be desired for many use cases (for compatibility/interoperability), but the spec allows for a wider range of characters used here, so this should probably reasonably be a configuration toggle.The text was updated successfully, but these errors were encountered: