"bat" is not a better version of cat, it's a completely different tool. cat is short for concatenate. If you want to view a file use less, and if you want syntax highlighting etc. then use view (comes with vim).
Or is because you deploy your scripts to other machines where ripgrep may not be present, but grep will?
* Deterministic
* Standard
* Written in c
* Equally performant (where it matters)
* Doesn't show colour or line numbers unless I tell it to
* Doesn't watch .gitignores unless I tell it to
(I should have said this in my first comment, but I'm the author of ripgrep, and I'm just generally interested in learning more about the differing use cases for these tools, in the words of users. I certainly have my own ideas about the question!)
some | commands | grep ERROR
alias g=grep
EDIT: The real differences (at least the most important ones for me) between grep and these tools are 1) they format filesystem searches better for human viewing, 2) they provide more useful defaults, 3) in the case of ag, you can specify a max line width to avoid the terminal being filled by a matching line that has a ridiculous length, which typically happens with generated files, 4) they're supposed to be faster although I personally don't have searches big enough to notice the difference, but I imagine it's a big deal to others.
% grep "die()" * [...results with functions named die()...]
% rg "die()" Error parsing regex
I reach for grep when I need to do non-regex searching. Can't remember how to do an fgrep fixed-pattern style ripgrep.
great tools andrew: I use them every day and install them first thing on a new box. know that your code really helps
For ripgrep, you can enable literal search the same way you do it in grep: with the -F flag.
Thanks for responding!
EDIT: I just saw your comment where you stated you're the author of rg. I honestly haven't tried it before until now. It seems you also chose to output line numbers by default in that case, but it's nice that you have -N. If you don't mind me asking, do you have an option like ag's undocumented -W which allows specifying a max line width for which a matching line is displayed? Regularly when searching a hierarchy a match happens on a generated file where everything is on a single line and so my terminal prints the millions of characters line. -W displays an bracketed ellipsis once the max width is reached on a line.
Right. When you run ripgrep with its output connected to a tty, then its output is "prettified." That means results are grouped by file, colorized and include line numbers. But if you aren't connected to a tty, then ripgrep reverts to the standard grep format (e.g., no line numbers). This means you should be able to use ripgrep in pipelines pretty much exactly like you would use grep. It just does the right thing. You can test this easily by comparing the output of `rg <pattern>` with `rg <pattern> | cat`. ag also does this to some extent (by disabling grouping and colors), but does still include line numbers in most cases.
> do you have an option like ag's undocumented -W which allows specifying a max line width for which a matching line is displayed?
Yes. That's the -M/--max-columns option. I have that set by default in my config:
$ cat ~/.ripgreprc
--max-columns=500
--colors=match:bg:0xff,0x7f,0x00
--colors=match:fg:white
--colors=line:none
--colors=line:fg:magenta
--colors=path:fg:green
--type-add=got:*_test.go
$ echo $RIPGREP_CONFIG_PATH
/home/andrew/.ripgreprcThat sounds both good (for direct use) and bad (for developing scripts) at the same time. And it's a general pattern. I wonder, is there a standard UNIX/Linux way of saying "run this, but pretend I'm not connected to a tty"?
I don't think this has been an issue for me yet, but it has tripped some people up, yes. Overall, I think it's worth it.
Yes, I knew that. What I meant to say is that in the particular case of "rg pattern file", I feel it doesn't to the right thing. I understand that my usual usage of that kind of invocation may not be like the majority, so I understand that other people might prefer that default as it is right now. In my usual usage, though, I feel the numbers are burdensome, because I have to imagine the output without it to know what I'm passing in to the next command I've yet to type in the pipeline. I can't remember the last time I used that kind of invocation to look for the line number a match was in. I only ever use the line numbers when matching a directory or multiple files.
> Yes. That's the -M/--max-columns option. I have that set by default in my config:
That's awesome, and thanks for sharing your config.
"Whenever bat detects a non-interactive terminal, it will fall back to printing the plain file contents."
The project is still rough around the edges but mostly good.
I'd like to recommend pygmentize also for syntax highlighting. Works like cat and supports a lot of languages. But since pygmentize is written in Python, it may not run as fast as bat. (I haven't tried bat though, because pygmentize is fast enough for my daily use cases.)