-
Consider these documents in a single file # test1
foo: bar
---
# test2
foo: bar2
---
# test3
foo: bar3 I would consider all the test1, test2, test3 to be yq ea 'head_comment' ./input.yaml which produces the comment for the first document:
Then to dig deeper I found this in the docs, to find where all comments are. Notice that in document 2 and 3 the head_comment is attached to the - p: ""
isKey: false
hc: test1
lc: ""
fc: ""
- p: foo
isKey: true
hc: ""
lc: ""
fc: ""
- p: foo
isKey: false
hc: ""
lc: ""
fc: ""
- p: ""
isKey: false
hc: ""
lc: ""
fc: ""
- p: foo
isKey: true
hc: test2
lc: ""
fc: ""
- p: foo
isKey: false
hc: ""
lc: ""
fc: ""
- p: ""
isKey: false
hc: ""
lc: ""
fc: ""
- p: foo
isKey: true
hc: test3
lc: ""
fc: ""
- p: foo
isKey: false
hc: ""
lc: ""
fc: "" So the document 2 and 3 head comments can be extracted like
This seems like a faulty behavior to me. Can the head_comment be fetched from all documents without having to know about the document keys? 😕 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Yeah it's definitely faulty, and a known issue. Comment handling is something I've been trying to beat the underlying yaml parser with a stick with - with the way the parser attaches comments to various nodes it's really hard to provide a consistent intuitive behavior for all the various scenarios :( TLDR I had to do some head pre-processing to fix other header comment parsing issues - but this causes issues in other places, like this. You can turn off the pre-processing and get document 1 to be consistent with document 2 and 3:
Just a word of warning that without the header-preprocessing you can get some issues with block comments at the start of yaml files (especially with newlines; and document separation tags at the start/end of the comment block. |
Beta Was this translation helpful? Give feedback.
Yeah it's definitely faulty, and a known issue. Comment handling is something I've been trying to beat the underlying yaml parser with a stick with - with the way the parser attaches comments to various nodes it's really hard to provide a consistent intuitive behavior for all the various scenarios :(
TLDR I had to do some head pre-processing to fix other header comment parsing issues - but this causes issues in other places, like this. You can turn off the pre-processing and get document 1 to be consistent with document 2 and 3:
Just a word of warning that without the header-preprocessing you can get some issues with block comments at …