yq: command-line YAML, JSON, XML, CSV and properties processor
github.com
github.com
[1] https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...
"The plain (unquoted) style has no identifying indicators and provides no form of escaping. It is therefore the most readable, most limited and most context sensitive style."
Which reads to me that they expected people to treat the plain style as a convenience that had notable downsides.
Edit: Note that this is the "plain" style, where there's also single and double quoted styles.
Maybe, but unquoted strings not being the right choice for all use cases (or, similarly, structure-by-indentation not being) doesn’t show that, since YAML supports unquoted and quoted strings, and supports both indent-sensitive “block style” and delimiter-based “flow style”.
It is erroring on `*.html`, which is reasonable because `.html` is an invalid anchor identifier, though the error is not that useful. The parsing of the unquoted version numbers also seems to be "correct", in that things that look like numbers are supposed to be parsed as numbers.
2. The unquoted aliases (*.html, *.png) are invalid: that yq errors on them is the correct output. (I.e., if you want those as literal strings, they MUST be quoted.)
And I don't much like them as an end-user either, at least where there's a decent operator as an alternative.
(The definition of "decent" starts with "good documentation", looking at you Prometheus operator.)
And yes let’s not even get into the state of off the shelf charts.
We use both tools equally where ease of use is the primary driving factor.
I wish MySQL and AWS could have figured out a way to adopt it, or a subset of it, rather than each using different ones. Now I have varying levels of knowledge for 4-5 variations of JSON path semantics/standards, it’s annoying.
So not only do we end up learning multiple JSON path variations, but most of them are nearly useless for anything but the simplest use cases.
I appreciate the intention of including JMESpath in awscli, but I quickly dropped it in favor of piping the JSON results to jq.
There is a fork (https://github.com/jmespath-community/jmespath.spec), but it seems unlikely to be used by the aws cli (https://github.com/aws/aws-cli/issues/7396). Although, for that matter jq is semi-abandoned itself.
For AWS CLI, you can just output unfiltered JSON and pipe the results through jq; the filtering is client-side anyway, so it’s not like you are losing anything doing external filtering vs. filtering within the AWS CLI.
I love yq and jq, but imo the core feature they’re missing is queryability. The problem is that afaia the jq syntax doesn’t support things like “where value = x”.
There’s another lesser known but imo better querylang called JSONata [0], which is basically a querying and reshaping syntax for structured data.
I’m working on this in my spare time but if any know of one that exists so that I don’t have to GO (lang) down a rabbit hole, please do share.
My go to lately has been csvq (https://mithrandie.github.io/csvq/). Really nice to be able run complicated selects right over a CSV file with no setup at all.
"I have a <very large> YAML file, and it takes yq <some long time> to parse, whereas <some workflow I use written in rust/c> takes <much less time>".
"Go is slower than Rust, the author should have written it in that".
It's likely for most YAML documents you encounter, the difference between using Go and using Rust or C is negligible. -- Though, if this isn't true, some numbers would be useful, too.
A comment like "Go is a bad language to use" is just a thought; but it's also a low-effort dismissal of something someone has put effort into, and of a tool that's quite useful.