"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).
Most tools mentioned are completely different tools from the ones they're suggested to be better versions of. I understand the comparison is for specific use-cases. For example, csvkit is far better than trying and failing to parse CSV with awk, but it's very much useless for any other type of text format. Same thing with jq (a JSON query tool) vs grep (a general text search tool). The only ones I can agree with in the general case are htop > top and ag || ack > grep (though I still prefer grep sometimes).
If you don't mind me asking, in roughly what cases do you reach for grep instead of ag || ack? Is it a familiarity thing, or specific features or something else?
Well there's the portability of grep which is better for scripts. Besides that, most if not all times I do a simple `ag pattern file`, I'm interested only in the results and not in the location. I'm probably preparing the pattern to output something to provide to another command via stdin or substitution and at those times (which is also in the interactive command line), I want to see exactly what I'm going to pass in. To remove the numbers ag adds by default, I have to use --nonumbers, which is weirdly long given that one of the main benefits of ag is the brevity of the commands (ag is short and easy to type, no need to include options -r, -i, -P, or -n (when needed)). Instead of using that option, I just switch to grep. I really wish ag changed that default to be consistent with grep and ack or at least change the way its options are negated, like making it a short option and negating like +N.
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.
> It seems you also chose to output line numbers by default in that case, but it's nice that you have -N.
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:
> 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.
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.
> 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).
That 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"?
Scripts tend to be shared, so portability matters. grep alternatives, while great for interactive use, are generally not worth being an extra dependency to install.
I use rg on all my scripts that I won't be sharing with others. Anything that needs to be used by other people / needs to be run on any machine that I don't control, uses grep instead.
ag is made to search code specifically. grep is a more general purpose text search tool and better suited (imho) for handling data (in contrast to code). Also, it’s always installed. I’ve never been on a machine with ag unless if I’ve installed it myself.
Errmm, yes, I'm familiar with the difference in motivations behind the tools. I guess what I'm looking for is specific examples of things that cause you to use grep instead of ag. Ubiquity is a good one. But let's say you have both ag and grep. When do you reach for one and why?
(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!)
Ah yes! That is a good one too. That's because grep uses "basic" regexes by default, and this sort of use case is one area where they work nicely. The downside is needing to remember which meta characters need to be escaped.
For ripgrep, you can enable literal search the same way you do it in grep: with the -F flag.
They're really meant for the same thing. You can also search the filesystem with grep by using -R and providing a path explicitly like `grep -R pattern .`.
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.
I'm starting to use vimpager after realizing I don't feel good seeing 2 different coloring on the terminal and in vim, instead, this way, whatever your vim supports (color, utility, key binding) can be carried over as a pager.
The project is still rough around the edges but mostly good.
> if you want syntax highlighting etc. then use view
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.)
