It might be worthwhile to just learn how jq works. At the end of the day, you need to learn some language to parse json. I hate DSLs too, but I cannot think of anything as useful and concise as jq.
> but that ends up being at least as nasty as the JQ script
That's exaxtly why jq is so nice. Nice alternatives just don't exist
Write a simple Python script, parse JSON into native objects, manipulate those objects as desired with standard Python code, then serialize back into JSON if necessary. Voila, you have a readable, maintainable, straightforward solution, and the only dependency (the Python interpreter) is already preinstalled on almost every modern system.
Sure, you may need a few more lines of code than what would be possible with a tailor-made DSL like jq, but this isn't code golf. Good code targets humans, not "least possible number of bytes, arranged in the cleverest possible way".
jQ integrates very nicely into bash script. Especially in between pipes a short&simple jq-snippet can work wonders for readability of the overall script.
On the other hand, if the bash script becomes too complex it may be a good idea to replace the entire bash script with python (instead of just the json-parsing-part)
Many of them are not short and simple though. And each time you do a some transformation, you pretty much need to go in/out of jq at each step of it want to make some decisions or get multiple types of results without processing the original multiple times.
... if the reader happens to be familiar with the niche language "jq".
Otherwise, you may as well have put some Akkadian cuneiform in there.
jq seems slightly better than those...
Eh. Linux/Unix has always had an affinity for DSLs and mini-languages. If you're willing to work with bash, sed, awk, perl, lex, yacc, bc/dc etc. jq doesn't seem like it should cause too much consternation.
Second to this, I've mostly used jq to look at OpenAPI/swagger files, again just doing one-off tasks, such as listing all api routes, listing similarly named schemas, etc.
From what I've seen in the companies I've worked for, this is fairly consistent, but naturally I can't speak for everyone's use-cases. At the end of the day, I don't think most people use jq in places where readable or maintainable would be most appropriate.
https://gitlab.com/nbdkit/libnbd/-/blob/master/info/info-jso... https://gitlab.com/nbdkit/libnbd/-/blob/master/info/info-map... https://gitlab.com/nbdkit/nbdkit/-/blob/master/tests/test-ex... https://gitlab.com/nbdkit/nbdkit/-/blob/master/tests/test-ta...
(I picked a few completely at random from dozens and dozens)
It's beauty is the simplicity and portability.
Python is often not installed in server environments unless it's a runtime environment for Python.
Want to use a non standard library? Now your coworkers are suddenly in Python dependency hell. Better hope anyone else that wants to use this is either familiar with the ecosystem, or just happens to have an identical runtime environment as you.
Or someone could just curl/apt/dnf a jq binary to use your 3 line query, instead of maintaining all of this + 200 lines of Python.
(?:[A-Z][a-z]+_?(\d+))
I'd argue it's good code if you don't have to sift through lines of boilerplate to do something so trivial in jq or regex syntax.
Putting that frustration on jq seems like a case of transference.
Of course not, but compared to every alternative today, jq is eons better than everything else. It's conciseness, ease of use, ease of learning all make it awesome. So as of right now, it is the nicest thing to use by far.
Personally though, I don't think I do wish for better. Jq is missing nothing that I want.
It is also a single executable, written in clojure and fast. Among other niceties, you don't have to learn any DSL in this case -- at least not if you already know clojure!
echo '[{"name":"_skip"},{"name":"alpha"},{"name":"_other"}' | \
jq '[ .[] | select(.name|test("^_.*")|not) | . ]'
$[?(@.name =~ /[^_].*/)]And, while whatever is powering https://jsonpath.com/ does honor your syntax, albeit with an absolutely useless result:
[
{
"name": -1
},
{
"name": -1
},
{
"name": -1
}
]