Hacker News new | ask | show | jobs
by ser0 1718 days ago
For me The Silver Searcher (Ag) has replaced trying to memorise various grep flags. Its defaults produce largely what I'm looking for without needing any flags.

On occasions where I do need more advanced features such as excluding file patterns or directories, I find the man page to be pretty easy to understand.

4 comments

Wow this is amazing. It's super fast and has a very easy to follow help page, plus the formatting is pretty awesome. I just did a quick benchmark searching for `kthreadd` using grep and ag and it's magnitudes faster than grep. Thank you for sharing this. I hope I can convince the network admins at my workplace to install this tool.

In addition, A+ for the ag's design for `mmap()` ing files instead reading them into a buffer.

Bench marks: Using Grep

```bash $ time grep -Rsn "kthreadd" ... real 0m25.341s user 0m5.738s sys 0m4.074s ```

Using ag: ```bash $ time ag "kthreadd" ...

real 0m2.182s user 0m1.306s sys 0m1.773s ```

> I just did a quick benchmark searching for `kthreadd` using grep and ag and it's magnitudes faster than grep.

I'd be careful with that. You may have just tested the awesomeness of linux caches :-)

Yes, it "looks" magnitudes faster:

  ]$ time grep -Rsn "kthreadd"
  ...
  real    0m26.895s
  user    0m3.131s
  sys     0m3.151s

  ]$ time ag "kthreadd"
  ...
  real    0m0.906s
  user    0m1.930s
  sys     0m1.186s

  ]$ time rg "kthreadd"
  ...
  real    0m0.860s
  user    0m1.756s
  sys     0m1.123s
But wait, somehow grep got magnitutes faster too:

  ]$ time grep -Rsn "kthreadd"
  ...
  real    0m2.961s
  user    0m1.979s
  sys     0m0.959s
And we can make both ag and rg slower:

  ]# echo 1 > /proc/sys/vm/drop_caches
  ]$ time ag "kthreadd"
  ...
  real    0m17.761s
  user    0m2.371s
  sys     0m2.728s

  ]# echo 1 > /proc/sys/vm/drop_caches
  ]$ time rg "kthreadd"
  ...
  real    0m19.276s
  user    0m1.859s
  sys     0m3.063s
I'd suggest ripgrep [0] for even faster results.

[0] https://github.com/BurntSushi/ripgrep

ripgrep doesn't seem to just be fast, it has a good set of features compared to the alternatives too! https://beyondgrep.com/feature-comparison/
I always wondered what the differences between all those mysteriously named search tools are, great resource, thanks for sharing!
Might also want to use FZF as selection interface for the ripgrep results, if applicable.
It's Rust-based, though, and is thus difficult to get installed on older systems.
Which systems? I have a ten year old laptop it works fine on.
I also default to use ag now and it is good at picking up things like .gitignores to exclude files. It works very well, I just wish it had a flag to limit the size of files searched because if a large file is found it can make the results harder to parse visually and most of the times when programming I only want to scan files that are under 100k (at most ... probably 10k is fine for a first pass).

This is really bad if the large file is some concatenated minimized javascript thing that is one massive line, then that really makes the results harder explore ( I tend to `ag foosearchterm | less -R` at that point) . Perhaps capping the line length in a result is another solution, if a line is over a couple hundred chars only show the relevant portion.

If you use ripgrep, -o will only show the matching part of the line. It also has a --max-filesize flag.
Thank you! I just tried it and --max-filesize worked great, ... -o also worked however it would be nice if -o showed a bit of context around the match (maybe 50 chars or so before and after), still useful all the same. Thanks again.
give ripgrep a try. it is probably better than anything else that you might have tried.

if you are using emacs, then rg (emacs interface to ripgrep) is just excellent. that when combined with embark and wgrep is almost magical in what it can do.

Agree, I love Ag. My only grief is that it isn't standard and I still need to be able to use grep.