psych icon indicating copy to clipboard operation
psych copied to clipboard

Puzzled by \n\n behaviour in a yaml file

Open tjoyal opened this issue 6 years ago • 2 comments

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 avatar Jun 12 '18 21:06 tjoyal

@tjoyal did you find any way to improve the output?

Matt-Yorkley avatar Oct 24 '20 09:10 Matt-Yorkley

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.

tjoyal avatar Oct 24 '20 11:10 tjoyal