impossible to understate the value in: not frequently fucking up your ability to run the critical/mundane/everyday/musclememory commands you've come to rely on after maybe 100+ invocations/week as far back as you can remember just because someone you've never met wanted to bump the .ruby-version in your java monorepo
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.
Or 'jq', if you include the binary name.
Hardly "bloated".
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
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
It's a very flexible tool for filtering, querying and manipulating JSON data, but when run with no arguments, it performs a no-op transformation that just pretty-prints its input.