I never understood terminal file managers... If I want to find a file, I use find or fzf. If I want to list files in a directory, I can use tree or ls. If I want to move files around, cp and mv work great.
If I want something more rich or discoverable, I'll just move to a GUI, which handles this much better.
Try to think of it as an endless ls-cd loop with tons of automated functionality few keypresses away. Also, please try the type-to-nav mode in nnn.
Also, find/fzf etc. are useful as long as you are not on a slow disk and a mid-range Android device/the Pi. If you are saying you are OK with scanning the whole filesystem every time you are looking for something that can be anywhere under /, I simply don't prefer that.
That'll print the list of files even in a populated directory like /usr/bin and leave me at the prompt with the last few files listed above. As soon as you want the list of files not to go away so you can control/manage/examine them, you are talking of a file manager.
Find has a pretty poor API in my opinion. Replacing it with fd is a simply improvement similar to ripgrep over grep.
Separately, I have a bunch of keybindings to load sets of files into fzf for easy access. Things like modified files, files changed in current branch, branches modified in the past six weeks. All of these have make working for a large code base much easier for me with little downside except have to piece them together on a new machine.
I found switching to fd challenging. fd makes some of the options easy. But find and fd are not syntactically the same. I guess I didn't spend enough time with it.
No, you are probably right. My main usage of find is `find ./ -name "blah"` which with fd is simply `fd blah`. If you are doing more complex finds then it may very well not be a good replacement for all find usage.
I just checked both fd and ripgrep and they both seem like wonderful tools. I've been using a very long and slow bash script for what ripgrep to make grep -R avoid my node_modules directory.
Being realtively new to Linux both these commands will be super helpful to me. Are there any other command line tools you will recommend?
For other things like files changed in current branch I've just kludged together aliases:
branch_files='git log --decorate --pretty=oneline --abbrev-commit --name-only --no-merges --first-parent main..HEAD | fpp'
(fpp extracts file paths from output)
If you use zsh it can also helpful to setup suffix aliases so just the filename is bound to an application. For instance `alias -s {rb,erb,rake,css,js}=vim`
I like using terminal file managers for quickly traversing many nested directories, where I'm not sure where I want to go. I can use it to browse around and hjkl is familiar as a vim user.
With ranger[0], I can even use it as an alternative to cd, which is often the most convenient (I usually want a terminal in the last directory I browsed to, not the place where I opened the file manager[1]).
I hope to find a way to use nnn similarly, but it (like ranger) doesn't seem to support this out of the box.
> but it (like ranger) doesn't seem to support this out of the box
No utility can support cd-on-quit out of the box because a spawned process can't send the $PWD to the parent directly when it quits. It needs tweaks in your shell's rc file. nnn also needs the same instrumentation.
I use them because they fit better in my workflow. I use a tiling WM and vim bindings everywhere I can because keyboards hurt my hands less than mice. I use them just for discovery, if I know what I want mv / cp / find are better. tree doesn't work so well if you have a sub-directory with hundreds of object files, etc.
In my life I’ve occasionally used emacs dired-mode[0] to do medium-sized file operations; more than just 1 or 2 files, but not worth building a script w heuristics.
Hasn’t been a problem for me for years. It seems to me that often this argument is based (directly or indirectly) from conditions 20 or more years ago. I think Emacs itself hasn’t changed much (it’s gotten better, but not fundamentally different), but the supporting environments (read: hardware) easily make for a usable experience. There are better poster children for bloat these days.
I suppose I've not tried it in any sort of extreme scenario, but it's not clear to me what dired would be slow at. Functions like copy-file are implemented in C.
They can be handy if you're in the middle of something else, and you need one without distraction.
I don't personally use them, but I live in emacs for many hours a day so I do use its integrated directory-manager (dired) to perform simple operations.
My main use nowadays is to select files. i.e. I have a folder with many files, and I need to cp or mv some of them elsewhere. If it's more than a handful tab completing them is a chore, so I run "mc".
A gui doesn't help, because usually I'm on a remote server somewhere (using SSH).
Take a look at Ranger. Ranger gives you the ability to do things like bulk edit files within a vim editor. Try doing this on the cli with the same efficiency and speed. This is where a term file manager really begins to shine...
That doesn't really help - something like "POSIX-compliant, follows Linux kernel coding style" doesn't really indicate what it's useful for.
My question isn't snark. It's more like "what is the usecase and what advantages does it have over standard terminal workflows?"
FWIW:
My main file manipulations I need to do are within vim when working on a project. I typically use nerdtree for this, but having a project that's consistent in my environment would be good.
I do other manipulations using standard tools like ls/rm/etc. what advantages does this have over those ?
Thanks for voicing what I've been feeling. I've just never got any kind of file browser in the terminal. As you said, there are better tools for browsing that require less investment in a partiuclar way of thinking.
Why do I want to invest in the particular way of thinking required to use GUI file browsers when I have a plethora of options in the terminal? (ranger, lf, mc, and nnn being the better know ones, but there are others too)
If I want something more rich or discoverable, I'll just move to a GUI, which handles this much better.