[avidal]

Have you seen gron[0]? It's similar: flattens JSON documents to make them easily greppable. But it also can revert (ie, ungron) so you can pipe json to gron, grep -v to remove some data, then ungron to get it back to json.

[0] https://github.com/tomnomnom/gron

[Fnoord]

Actively developed and written in Go.

The project linked to is from 2014 with last update in 2015.and it is on NPM...

What is left to say? Thank you!

[edflsafoiewq]

What's wrong with it not being updated in 5 years? It's a simple script. It's probably stable and doesn't need to be "actively developed".

[sethammons]

I see this sentiment a lot. I agree with you, simple things can be done and don't need active development.

[Apaec]

I much prefer jq[1]. Actively developed and written in C.

[1]:https://github.com/stedolan/jq

[heyoni]

Used to be written in php right?

[wooby]

I haven't seen that one, but it looks very similar to the one I use: https://github.com/micha/json-table

[krick]

That's actually a nice lifehack. Much simplier than jq. Unfortunately, would be harder to make all kinds of logical conditions for which jq allows (even if not that intuitively).

It still feels like there must be something in between, some way to make queries with json more naturally, than with jq, yet with enough power.

[jolmg]

jq is certainly a unique language, which makes it unfamiliar to work with. Intuitiveness and natural feeling comes when one has gotten familiar with it after a bit of practice and reading the manual, though. It's a very well thought-out language. A very nice design.

It might help to recognize how it's influenced by shell languages and XPath, if you're familiar with those.

[krick]

Well, no arguing there, it is indeed. And I use it from time to time. However, it's not like I need a tool like that every day, and if I'm no using it for a week I usually need to "learn" it all over again.

[inferiorhuman]

What does grep + gron give you over jq?

[pfranz]

jq seems very powerful. I don't deal with json all that often and my most common use case (by far) is `jq '.' -C` and it took a few tries for me to remember that syntax.

The idea of flattening, grepping, then reverting sounds very appealing and sounds like a better fit for me.

[jolmg]

> `jq '.' -C` and it took a few tries for me to remember that syntax.

I don't think you really need neither `.` nor `-C`. Just `jq` seems to do the same colored output of the input by default.

[pfranz]

It does look like neither are needed if you pipe a file in jq, but `jq . file.json` requires the `.` and if you're pipeing into a pager, like less, you need both `.` and `-C` to get colored output (that was the case with the alias I had pulled up). I am using 1.5 and haven't looked to see if 1.6 changes this.

[jolmg]

I see. I doubt that behavior has changed, then.

`-C` would be required when piping because most of the time (with the exception of piping into less) when stdout is not a terminal, it doesn't make sense to include terminal color escape sequences. You'd end up with those codes in your files, and grep would be looking at them for matches, for example.

`.` would be required when passing the file as an argument instead of stdin, because jq interprets the first argument as jq-code. If you don't include `.` it would interpret the filename as jq-code.

[pfranz]

`.` is still needed if I'm pipeing in json--but only when I'm piping out. Otherwise help goes to stderr and nothing goes to stdout.

I do honestly think jq is a cool and powerful tool. I also appreciate little things like auto-color when appropriate--git also does this. Git also uses your pager, which might trivialize my personal use case.

[dirkt]

Wrong question: It's not a competition.

There are cases when you have some complicated json and just want to search for stuff. Then you use grep + gron.

There are cases when you want a complete json processing tool. Then you use jq.

You can probably simulate each approach with the other approach, but the code needed to this is just too tedious to write. So you use whatever tool fits your use case.

[nerdponx]

No, but you still have to make a decision about which tool to use. So it's helpful to have a sense of the use cases for each.

[ElegantGiraffe]

I find it useful when I don't know what the json schema is. Then you can just do a quick gron + grep and find where the interesting parts of a large json document are.

[webo]

as far as i can tell, jq doesn't do flattening .

[pstuart]

Not built in, but @jolmg posted a script here which does the needful.

[lucb1e]

Maybe GP meant that jq can do selection as well, i.e. that grepping is redundant after jq. But jq is much more complicated to learn and grep works on all inputs (not just json), so it makes a lot more sense to learn and use grep properly.

[ori_b]

Simplicity.

[news_hacker]

Love the greppability and reconstructability. This should be the submission.