Doesn't understand key 'on'

[sporksmith]

Notably this came up while trying to parse github workflow configs.

Here's a minimal example:

$ echo "on: foo" | shyaml get-value on
Error: invalid path 'on', missing key 'on' in struct.

And version info:

$ shyaml -V
version: 0.6.1
PyYAML: 5.3
libyaml available: False
libyaml used: False
Python: 2.7.17 (default, Nov  7 2019, 10:07:09)  [GCC 7.4.0]

[tomjn]

@sporksmith it's likely your on is being interpreted as true, this snippet works for me with on wrapped in quotes:

echo "'on': foo" | shyaml get-value on

[sporksmith]

@tomjn Ah, I didn't know you could quote keys. Thanks for the workaround, though I still wonder whether a conforming parser ought to be able to handle it without the quotes.

[tomjn]

I think it’s a part of the spec, there’s the common refrain that the country code for Norway evaluates to false in YAML without quotes

[vaab]

Well, shyaml is a thin command line layer on top of PyYAML, this project provides implementation of YAML spec v1.1 in both full python and C (called libyaml).
You can check which version of both these layers with shyaml --version.

More on the topic: https://stackoverflow.com/questions/42283732/are-on-and-off-supposed-to-be-interpreted-as-true-or-false-in-yaml-1-2

PyYAML and libyaml are only implementing YAML spec v1.1, which specifiy that on and off should be considered boolean values... and it seems that changed in YAML spec v1.2 where it only interpret 'true'/'false' as booleans.

I understand the issue, and I wish to keep this open to see what are the viable option to move towards YAML 1.2, but don't expect anything in terms of date of when this will be added, unless you can provide time and code to move forward.

[sporksmith]

Thanks for the explanation! I don't have time to dedicate to improving this, but it's good to have the workaround and understand what's going on here.