Hacker News Reader

Comment by loudmax | Hacker News Reader

I applaud this project's focus on correctness and efficiency, but I'd also really like a version of `jq` that's easy to understand without having to learn a whole new syntax.

`jq` is a really powerful tool and `jaq` promises to be even more powerful. But, as a system administrator, most lot of the time that I'm dealing with json files, something that behaved more like grep would be sufficient.

View on HN

Have you tried `gron`?

It converts your nested json into a line by line format which plays better with tools like `grep`

From the project's README:

▶ gron "https://api.github.com/repos/tomnomnom/gron/commits?per_page..." | fgrep "commit.author"

json[0].commit.author = {};

json[0].commit.author.date = "2016-07-02T10:51:21Z";

json[0].commit.author.email = "mail@tomnomnom.com";

json[0].commit.author.name = "Tom Hudson";

https://github.com/tomnomnom/gron

It was suggested to me in HN comments on an article I wrote about `jq`, and I have found myself using it a lot in my day to day workflow

Thank you so much. This seems like a saner approach for some simpler use cases.

It flattens the structure. And makes for easy diffing.

There's also this awesome tool to make JSON interactively navigable in the terminal:

https://fx.wtf

https://jless.io/ is similar, and will give you jq selectors so the two combine very well. (fx might have that feature too, I dunno)

Ah thanks, jless is actually the one I was originally thinking of and trying to find! :D

You can also mimic gron, including support for yaml with

yq -o=props my-file.yaml

Doesn't work in my terminal. When you recommend yq behavior, please specify which yq you're using. There are at least two incompatible implementations.

This is awesome, thanks! Not OP, but this will help me to write specifications for modifying existing JSON structures immensely. It's kind of a pain parsing JSON by (old man) eye to figure out which properties are arrays, and follow property names down a chain. This will definitely help eliminate mistakes!

Also try jless[0], it's amazingly convenient and it shows you a JSON path at the bottom of the screen as you navigate.

[0] https://jless.io/

This looks some much better as an ad-hoc tool. Would be cool if it supported more formats - plist, yaml, xml (hoow to do body, or conflicting attr/elements)

One of my coworkers really likes Miller: https://github.com/johnkerl/miller

The idea is that you get awk/grep like commands for operating on structured data.

ChatGPT excels at producing `jq` incantations; I can actually use `jq` now…

> I'd also really like a version of `jq` that's easy to understand without having to learn a whole new syntax.

Since JSON is JavaScript Object Notation, then an obvious non-special-snowflake language for such expressions on the CLI is JavaScript: https://fx.wtf/getting-started#json-processing

It is a little early to say, but I have been learning how nushell deals with structured data and it seems like it is very usable for simple cases to produce readable one-liners, and if you need to bring out the big guns the shell is also a full fledged scripting language. Don't know about how efficient it is though.

It needs to justify moving to a completely different shell, but the way you deal with data in general does not restrict itself to manipulating json, but also the output of many commands, so you kinda have one unified piping interface for all these structured data manipulations, which I think is neat.

From the data side, nushell uses polars for querying tabular data so it should be pretty fast. Not sure about its scripting language.

Obligatory reference to "gron" ("make JSON greppable"), which I find to be quite useful for many common tasks:

https://github.com/tomnomnom/gron

jq, and yq, are tools you spend an hour figuring out and then leave them in a CI pipeline for 3 years.

Maybe like SQL for relational algebra? Codd made two query languages that were "too difficult for mortals to use". (B-trees for performance was a separate issue)

But jq's strength is its syntax - the difficulty is the semantics.

there's got to be some syntax though. jq does a unique function that isn't defined in any other syntax. i'm with you, the jq syntax is weird and sometimes difficult to understand. but the replacement would just be some different syntax.

these little one-off unique syntaxes that i'm never going to properly learn are one of my favourite uses of chatGPT.

Reply on news.ycombinator.com