fsearch VS gron

Hi, author here.

Likely the most significant benefit is the more powerful query language. For example you can also search by file modification date or size and use boolean operators. https://github.com/cboxdoerfer/fsearch/wiki/Search-syntax

Yes, FSearch is the one I use, but it's not as great, per FSearch's dev:

> However, FSearch doesn't automatically detect changes made to the file system and update its index then. This is on the roadmap (it's called inotify support) but it'll never work as smooth as Everything on Windows, because the Linux kernel isn't particularly good at reporting filesystem changes

https://github.com/cboxdoerfer/fsearch/issues/26

Everything is comprehensive + instant + always up-to-date, that's so awesome a combo it's a pity it's Windows only

If you are new and wish a simple way to search, fsearch is a very nice tool.... https://github.com/cboxdoerfer/fsearch

You might consider grabbing the latest release at https://github.com/cboxdoerfer/fsearch/releases.

One other program I've been particularly enjoying recently is fsearch : https://github.com/cboxdoerfer/fsearch

If you don't need content indexing, Fsearch is an alternative. I've been using it for over a year now and it's been working flawlessly. Results are near instant and the db is in single digit megabytes.

But AFAIK nothing seems to use this, def not fsearch, they have an open issue - https://github.com/cboxdoerfer/fsearch/issues/26

Still remember those days of arguing on /g/ where linux longbeards stallman fanboys tried to say how this or that tool was good search... but I dont want to just find something, I want to use it that second, and I want the entire system indexed... after getting some webms to showcase that instant feel it got the message across, though later someone appeared with some dmenu trickery being similarly fast and useful... anyway Fsearch that appeared soon after me is the real deal.

gron (https://github.com/tomnomnom/gron) to transform it and query and then invert the transformation?

It buffers all of its output statements in memory before writing to stdout:

https://github.com/tomnomnom/gron/blob/master/main.go#L204

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 = "[email protected]";

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

> So all I want is a tool to go from json => line oriented and I will do the rest with the vast library of experience I already have at transformations on the command line.*

The tool for that is likely https://github.com/tomnomnom/gron

If JQ is too much, see GRON &| Miller

gron transforms JSON into discrete assignments to make it easier to grep for what you want https://github.com/tomnomnom/gron

Miller is like awk, sed, cut, join, and sort for data formats such as CSV, TSV, JSON, JSON https://github.com/johnkerl/miller

And jless [1] and gron [2].

This is the first I'm hearing of gron, but adding here for completeness sake. Meanwhile, JSON seems to be becoming a standard for CLI tools. Ideal scenario would be if every CLI tool has a --json flag or something similar, so that jc is not needed anymore.

[1] https://jless.io/

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