So in cases where the new "improved" tool departs from old standard [1], it just add one more thing, that can screw you, especially if it comes over as a replacement.

grepping for settings in dot files is not exactly a corner case for me.

And setting up aliases to me it's similar. It will just mess with you on systems when you don't have them set up.

I guess it depends what you primary use case is. I can see how a developer that spends most of his time on his desktop/laptop command line would find this good default.

[1] And that it does so silently. If something fails hard or errors on the side of not filtering, its less of an issue.

> So in cases where the new "improved" tool departs from old standard [1], it just add one more thing, that can screw you, especially if it comes over as a replacement.

The solution to this is so stupidly simple. If this is a problem for you, then _don't use the new tool_.

ripgrep is not a replacement for POSIX grep.

Repeat after me. ripgrep is not a replacement for POSIX grep. I've never once marketed it as such. Others might. Why? See the FAQ for an explanation.

> grepping for settings in dot files is not exactly a corner case for me.

It's not for me either. Why does everything have to be black and white? Just because it isn't covered by default doesn't mean anyone thinks it's a corner case. It is precisely because it is not a corner case that ripgrep makes it very easy to disable "smart" filtering.

And once again, of course, if you do not want to be bothered by this, then don't use the tool.

I don't expect ripgrep to change, or to cater to my needs, like you said I don't have to use it. I managed to figure that out on my own, but thanks anyway.

Perhaps I expressed myself poorly, or we are misunderstanding each other, but it doesn't really matter.

Thanks for writing ripgrep, I might not use the utility, but when I stared learning rust, ripgreps source was one of the sources I looked at as a nontrivial cli app.

Have a nice day.