How is gojq different? Cursory look at the README and it seems like it implements the same language.

My problem is the infrequency with which I need to use jq means I don't create a good learning feedback loop. The last time I used it though, I was able to walk down a decently complicated structure (indexed val in an array in a key in a hash in an array) and extract the data I wanted only having to google once. Like awk, though, I know there's a world of functionality I'm just not using.

You should checkout gron, it is great at flattening fragments of json.

https://github.com/tomnomnom/gron

Anytime jq is mentioned, gron should be mentioned shortly thereafter. It is a wonderful tool.

I have started using gron to understand the json structure to then write jq. Other times it does the job alone. It’s great.

You can pipe the output of gron into fzf, it makes it kinda nice for perusing the flattened json.

TIL. Thank you! I took a look and will definitely incorporate this in my work. Definitely a good idea.

It is indeed a reimplementation of jq in go, and the reason I use it over jq is many, one of which is that it produces more helpful error messages. In fact, I've moved jq to ojq (sometimes I want to check compatibility), and ln -fs gojq jq.

I feel like it's OK if you use it often, but when you need it once a year, I'm spending too much time trying to figure it out.

Some collection of typical problems and solutions would help I guess.

The manual (https://stedolan.github.io/jq/manual/) somewhat provides that. Quite a few sections have helpful examples, with links to the sandbox at jqplay.org.

The IMO not so good parts of that page are

- Quite a few section headers don’t make sense to novices

- I think the table of contents would be better if it had subheaders, ideally with one-line descriptions of the features (that probably would solve the issue above)

- not every section has examples

- some examples use fairly advanced features, making them harder to understand then necessary

I use it a bunch to string together web APIs, and you're absolutely right. The longer I go relying on my library of pre-written strings of commands, the harder it is to write a new one. And you're right again with your second point, because that same library makes for great reference material for myself.

jq is not OK for that exact reason. It's like sendmail, dividing the world into people smart yet obtuse enough to sit and learn its idiosyncrasies, and regular people that go mad and claw their eyes out whenever they try.

I tried, more than once, but I guess I'm not smart enough.

I'll never be intelligent enough to use jq properly.

I see folks have mentioned gron, and I also want to suggest:

- jello (PyPI) - yamlpath (PyPI) - dasel

I’ve been using ‚gron’ with good results

Yeah, I like the design goals, I just found the solution was worse than the problem it was solving.

I just use gron then grep for what I'm looking for.

Does it do more than just grep? That's awfully limited compared to what jq can do. I personally like jless for just searching and exploring.

gron is great, i have this in my init.jq file for fq (https://github.com/wader/fq). Sadly jq lacks a path_to_expr function so a bit harder to do it with that.

  def gron:
    ( path(..) as $p
    | getpath($p)
    | scalars
    | "\($p | path_to_expr) = \(tojson)"
    | println
    );

Ex:

  $ fq gron <<< '{"a": [1,2,{"b": 3}]}'
  .a[0] = 1
  .a[1] = 2
  .a[2].b = 3

Great for copy/paste into other expressions when poking around.