Open nemchik opened 3 years ago
This is not a bug in yq, but a peculiarity in the PyYAML parser's behavior (which yq depends on). Dumping a single scalar node in PyYAML will always produce a document end marker (...
) and there is no way to disable this behavior. A fix for this issue has recently been submitted upstream (https://github.com/yaml/pyyaml/issues/379, https://github.com/yaml/pyyaml/pull/438) and once it is merged and released, yq will no longer emit ...
in this situation.
Thanks! I'll subscribe to notifications for those.
Same issue. Looks like yq actually changed this behavior for https://github.com/kislyuk/yq/issues/93. Given that, I was trying to use sed to just strip off the explicit_end line, but as I'm a rank beginner with sed and average with bash, I couldn't make it work. Anyone have a working solution to use yq to query for a single scalar value and remove the unwanted explicit_end line folllowing the desired value?
The default behavior was not changed for #93. To query for a single scalar value without emitting the document end marker, just don't use -y
, or use head -n -1
to cut off the last line with the marker.
I am trying to parse the following yml:
With the following command:
I get the following output:
With the following command:
I get the following output:
In my use case I am actually passing in the filter as a variable, and in most cases I want the value of a given key, but in some cases I want the yml children of a parent, like so:
With the following command:
I get the following output:
And this is exactly what I want. If I don't use
-y
I of course get a JSON object that looks like this:But in this case I do NOT want the top and bottom curly braces or the quotes around the keys.
So in conclusion I am wondering why the
...
is included at the end of a single value output when using the-y
flag. Is that a bug, or is there a more specific way I should be trying to get what I want?I searched and the only possibly related issue I found was https://github.com/kislyuk/yq/issues/93 but that looks like they are intentionally expecting the
...
because they included it in their original file. In my situation...
is not included in the original file, and thus I would not expect it to be included in the output.