I tend to agree, regretfully.

I’ve unfortunately often seen coworkers spend half an hour painstakingly crafting and debugging a jq query, that could have been cobbled together in a few minutes with grep and sed.

I think the issue is that jq’s interface makes it really hard to “narrow in” on the right solution, whereas grep is much more forgiving.

I agree in the general case, but the syntax for pretty printing which is what he is doing is literally nothing.

Or 'jq', if you include the binary name.

Hardly "bloated".

i dont know if i'd call its syntax bloated at all.

jq is something i've hated learning but powerful beyond tying grep and awk together.

jq is a tool, and like every tool, requires some upfront learning. Once mastered its much more productive than the grep/awk/friends solution.

Take this example JSON

<pre> { "code": 42, "items": [ { "type":"color", "name":"red", "rgb": [120, 2, 2 ]}, { "type":"color", "name":"green", "rgb": [2, 120, 2]} ] } </pre>

for instance, to grab the rgb field for the color green... jq -r '.items | .[] | select(.name=="green") | .rgb

An alternative would be to use XPath 3.1.

I am implementing XPath in a tool called Xidel.

There the syntax for the example is much simpler: xidel - -e '?items ?* [?name="green"] ?rgb'

Depends what kabacha means with bloated. The XPath syntax is more verbose, but less cryptic

Agreed about the bloated syntax bit. Whenever I need to work with jq , I tend to trial with jid first and then use the actual syntax with jq. Convoluted if you think about it....