psych
psych copied to clipboard
Puzzled by \n\n behaviour in a yaml file
I could not find documentation on this behaviour so I thought it would be better to share about it and be told I'm wrong than to keep to myself.
In a piece I'm writing, I load, modify then dump a piece of data.
load
then dump
being called one after the other in a loop would always produce the same values. As a human reading the yaml representation, I can see an extra \n
being present in the yaml that is not there in the ruby representation:
require 'yaml'
yaml = <<YAML
en:
test: >
multiline a
multiline b
multiline c
YAML
data = YAML.load(yaml)
=> {"en"=>{"test"=>"multiline a multiline b multiline c\n"}}
new_yaml = YAML.dump(data)
=> "---\nen:\n test: 'multiline a multiline b multiline c\n\n'\n"
new_data = YAML.safe_load(new_yaml)
=> {"en"=>{"test"=>"multiline a multiline b multiline c\n"}}
There seems to be a behaviour where only 2 subsequent line returns would be considered as a actual line return:
YAML.load("---\nen:\n test: 'this\nis\na\n\ntest'")
=> {"en"=>{"test"=>"this is a\ntest"}}
While I understand that \n
in the yaml file structure might have a special meaning, I am surprised to also see it behave the same way when within a quoted piece of information.
I'm also wondering why when passing in a file using the >
format, that the output is returned as a quoted string instead of re-using the same format. I understand that the code cannot keep track of the "format used" when first loading the data as we only have a Hash, but in case of |
this is the format being used for a dump and it seems much more natural for a human to interact with it (main reason why I end up using yaml)
require 'yaml'
yaml = <<YAML
en:
test: |
multiline a
multiline b
multiline c
YAML
YAML.dump(YAML.load(yaml))
=> "---\nen:\n test: |\n multiline a\n multiline b\n multiline c\n"
So all of this makes me wonder if it is just about documentation as the intended behaviours or if these are symptoms of some kind of issue.
Any insight is greatly appreciated, thank you :smile:
@tjoyal did you find any way to improve the output?
No I'm sorry, it was a puzzling but not creating in my cases blockers or anything other than "know limitation". We ended up rolling with the current behaviour.