Sure, but that UNIX philosophy is what got us "grep -r" as the way to search files across an entire directory, which would then compose with stuff like xargs and parallel to be able to do things concurrently. I'd argue that ripgrep shows that that bundling together stuff sometimes does end up with a user experience that people prefer. The nuance lies in figuring out where the balance between "not enough" and "too much" lies, and so far I've yet to see a pithy statement like the UNIX philosophy encapsulate it well.

Alternately, maybe people's idea of what "one thing" is ends up being more subjective than it sounds (or at least depends on context). "Searching through my code" at least sounds like a reasonable idea of "one thing", and it's not crazy that someone might consider "don't search though the stuff that isn't my code, like my npm dependencies or my Rust build artifacts" would be part of "doing it well". Having to specify it every time would be annoying, so you might want to put it in a config file, but then if then if it ends up being identical to your gitignore, having to manually symlink it or copy it each time you modify it is annoying, so it's also not crazy to just use the gitignore by default with a way to opt out of it. Now we're just back where we started; custom .ignore files, fallback to .gitignore, and a flag for when you want to skip that.

That's why a bunch of tools agreed on something that was not tied to any one of them. What did I miss? We are explicitly not talking about .gitignore.

FYI, `-uu` turns off both ignoring based on special files (.gitignore, etc) and ignoring hidden files.

It's good if they can share syntax. You use the same English words to ask Alice and Bob questions, but when you say "So, tell me, Alice…" you don't want Bob to answer you instead. Using another tool's config by default, making it difficult/impossible to use the dedicated config is the most annoying thing I can imagine. If that's what rg does, I guess that must be the reason I couldn't switch.

It probably wouldn't have made sense twenty years ago (or 60 years ago, when IBM engineers first wrote about the Principle of Least Astonishment [1] in 1966).

But it does make sense today.

I'd argue that modern computers do many astonishing and complicated and confusing things - for example, they synchronize with cloud storage through complex on-demand mechanisms that present a file as being on the users' computer, but only actually download it when it's opened by the user - and they attempt to do so as a transparent abstraction of a real file on the disk. But if ripgrep tried to traverse your corporate Google Drive or Dropbox or Onedrive, users might be "astonished" when that abstraction breaks down and a minor rg query takes an hour and 800 GB of bandwidth.

It used to be that one polymath engineer could have a decent understanding of the whole pyramid of complexity, from semiconductors through spinlocks on to SQL servers. Now that goal is unachievable for most, and tools ought to be sophisticated enough to help the user with corner cases and gotchas that make their task more difficult than they expected it to be.

[1]: https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

It is already leaking today. I hope/expect that jujutsu takes over in the coming years.