tail -F output.log | ag --passthrough '.*PLUGH.*' grep '^|.*PLUGH.*'Or you could just use --passthrough. It's easy to remember, easy to type, it autocompletes, it doesn't interfere with your criteria.
tail -F output.log | grep --line-buffered TEXT | some-util-with-outputRipgrep works like a charm
Ack requires Perl, which I am not going to install just for that purpose.
alias rg='rg -S'
to my .bashrc so that rg had the same default case sensitivity as ag.
I understand alias'es and wrappers fine, but I like having the environment have some way to contribute. It's just my simple preference.
There's also the related #314 which makes even more sense- per project configuration. Sure would be great being able to download a project & have it already setup nicely for ripgrep! https://github.com/BurntSushi/ripgrep/issues/314
[1] https://github.com/BurntSushi/ripgrep#why-should-i-use-ripgr...
It's a fair criticism but I don't think it is designed to be misleading.
We're also working on a GNU grep vs. POSIX grep vs. BSD grep phrasebook.
Most annoying thing is that $ does not work with windows newlines.
https://github.com/ggreer/the_silver_searcher/issues/385
its been over 4 years... its had its chance.
But you know there's a -r for recursive, right? And unless you are using some historic relic of grep that is not GNU or BSD and doesn't understand the --include option you can just do:
grep -rin "needle" --include "*.foo" .
find . -iname '.*' -prune -o -iname '*.foo' -exec grep needle {} +
Modern file searchers, of which `ag` is one among others, accepts `--filenametype` argument and skips the `.git` subdirectory if it exists (by default, can be toggled), so `ag --python needle` will recursively search for needle in the the current working tree in all files whos filenames end in `.py`.
Yes, you could write a function to do the same in `find`, but then you're just being stubborn. (Which is fine; my .bashrc is littered with aliases and functions of me being stubborn, but if I have to copy my .bashrc file around, I might as well install my preferred searcher to the target system if available.)
Use --include and --exclude-dirs to do what you describe. (The latter is a good idea to set in your GREP_OPTIONS, unless you actually search .git directories.)
Excerpt: "Some might say that ag and ripgrep and any of the other tools I list on beyondgrep.com are competing projects, but I think that way of thinking is wrong. It’s only a competition if you see it as a competition. I’m not competing against anyone for anything: Clicks, dollars, popularity, etc. If someone uses ripgrep instead of ack, it doesn’t hurt me. It’s the difference between an abundance vs. scarcity view of the world. I choose abundance. I think most of us who work in open source do, too."
I never thought I would see the confluence of the "woo-woo" space abundance mindset and a blog post about an open source command-line utility. I must say I am intrigued.
If this explanatory medium doesn't substantiate the reasonability of a mindset of abundance in the minds of programmers, I don't know what ever will.
For me, raw speed is not as important as a rich feature set to support my code spelunking.
All in all, it'd still be nice to have a more comprehensive performance comparison page, which gets regularly updated. Bonus points if it shows how speed changes over time, similar to http://speed.pypy.org (the code for that is available, by the way).
Wishful thinking, I know, but hey, who knows... :-)
Thank you, have been trying to motivate myself to switch to ack/ag for a while. This seems like it might be what I needed.
The only serious feature you might miss is lookahead/lookbehind in regexes - that's missing by design since if you want guaranteed linear time search you can't have those.
I really like the discussion that lead to the decision of never including a pager:
As for search, I'm on Windows and I like to use FileLocator Pro.
To see a list of supported types and the matching file extensions: ag --list-file-types.
Just checked and rg does have something similar, but you need to specify the type as an argument to a flag: rg --type ruby foo.
Edit: the "-f" in the "cargo install" command is for updating; without the -f, it refuses to install over an already installed version. The first time you install, you can omit the -f.
1. GNU grep - GPLv3+
2. ack - Artistic License v2.0
3. ag (aka silver searcher) - Apache License 2.0
4. git-grep - GPlv2+/LGPLv2.1+
5. rg - MIT license
So with maybe the exception of rg, all are gpl compatible, that's great news.
Out of curiosity, what sort of searches do you do that smartcase is desirable? A meaningful number of people seem to prefer it, but I find that most of the time I want to be able to search for variables etc. case sensitively.
sary - a suffix array library and tools http://sary.sourceforge.net/
It finds words in O(log(n)) time by using an additional index.
Typically, if you want an index, you build an inverted index, which maps terms (e.g., n-grams or tokens in your favorite PL) to a postings list. The postings list contains all of the documents in which that term occurs.
Aren't those the same thing? Shouldn't they be grouped for better comparison?
Don't know how you'd pull it off in the current tabular format, but would be great to include some of the UX side of things: For example, I use rg almost exclusively because it has an easy-to remember syntax (`rg search-string` is a recursive search), attractively colored and well-organized output, and seems much faster compared to other tools in my use cases.
> Limit directory search depth
These could be the same item, the former is a special case of the latter.