I genuinely don't know what is going on here.
> I genuinely don't know what is going on here.
I basically live in my music library. However, every single pop artist offers songs that I don't like, are not in my library, and mysteriously have many millions of albums sold.
I genuinely don't know what is going on here.
Joking aside, have you ever tried to use some of these tools ? I use to not understand why people where using vim until I really tried.
No.
> I use to not understand why people where using vim until I really tried.
There's your problem. I respectfully suggest installing Emacs.
Also if I had to guess, the type of person who criticizes tools like jq, fzf, and ripgrep and struggles to understand some people's need for benchmarking tools like hyperfine would likely disapprove of fish as well.
The OP list is significantly cheapened by the various ls alternatives.
I use the command line a lot too and this is one of my most common commands, and I don't know of an elegant way to do it with the builtin Unix tools.
(And I have basically the same question for finding files matching a regex or glob [ignoring the stuff I obviously don't want], e.g., `fd '.foo.*'`.)
Hits in hidden files is not really a pain point for me
find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar
If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me switch `xargs` for `find`'s own `-exec` functionality:
find . -path '*/\.*' -prune -o -type f -name "*.foo" -exec grep bar {} +
For the record, I think `git grep` is probably the best builtin solution to the problem I gave, but personally I don't know off-hand how to only search for files matching a glob and to use the current directory rather than the repository root with `git grep` (both of which are must haves for me). I'd also need to learn those same commands for different source control systems besides git (I use one other VCS regularly).
Makes sense. If I had to do this frequently, I'd add a function/alias encapsulating that `find` incantation to my .bashrc, which I keep in version control along with other configuration files in my home directory. That way, when moving to a new environment, I can just clone that repo into a fresh home directory and most of my customizations work out-of-the-box.
1. I don't recommend using shell functions or aliases for this (e.g., `bashrc`) because then these scripts can't be called from other contexts, e.g., like Vim and Emacs builtin support for shell commands. This can easily be solved by creating scripts that can be called from anywhere (my personal collection of these scripts is here https://github.com/robenkleene/Dotfiles/tree/master/scripts). Personally, I only use Bash functions for things that have to do with Bash's runtime state (e.g., augmenting PATH is a common one).
2. The more important part though, is I don't always want to search in `*.foo`, I want a flexible, well-designed, API that allows me to on-the-fly decide what to search.
#2 is particularly important and drifts in philosophy of tooling, a mistake I used to make is building my workflow today into customizations like scripts. This is a bad idea because then the scripts aren't useful as your tasks change, and hopefully your tasks are growing in complexity over time. I.e., don't choose your tools based on your workflow today, otherwise you're building in limitations. Use powerful tools that will support you no matter what task you're performing, that scale practically infinitely. "The measure of a bookshelf is not what has been read, but what remains to be read."
find . -type f -name '*.foo' -not -path '*/.*' -print0 | xargs -0 grep bar find . -name '.*?' -prune -o -name '*.foo' -exec grep bar /dev/null {} +
alias grep='grep --exclude-dir .\* --exclude .\*'
grep -r --include \*.foo barIs that a zshism?
The only thing I use JQ for at work is parsing the copilot API response so I remember what the model names are - that's it! TBH, I could just skip it and read the json
ripgrep is something I have installed, but use only via text editor integrations. fzf is nice for building ad-hoc TUIs. fd may make sense (I’m told it’s faster than find), but I already know enough find.
The “next gen ls” family of tools in the article is baffling.