so I don't understand what the usecase for a terminal file manager is. I've always felt comfortable using cp/mv/mkdir/etc. but I feel like I'm missing out. Can someone explain how and why you'd use this ?
Three advantages I realized, having done a lot of cd/ls/cp/mv/rm and also having used a file manager:
- power user workflows may differ from typical dev workflows. Imagine things that a point-and-click file manager solves quicker than the command-line. Example: manually organizing a bunch of .mp3s, or cleaning out misc downloads. A TUI file manager makes these tasks quicker too.
- quick directory navigation. cd is slow. There's solutions for a better cd, involving z or fzf or whatever. But a file manager should solve it too.
- a file manager, especially a two-pane view, is cognitively easier. Better UX. Example: Having a src/ pane on one side and dst/ on the other, selecting a few src/ files, then performing a copy command. You get instant visual feedback to confirm that the files appeared in dst/. Compared to ls, cp file1 file2 file3 dst/, ls dst/. I always feel the need to ls after commands because the command-line doesn't give much feedback.
tldr: speed, ux, comfort. But if you're already comfortable with your tools, I think that's the most important thing.
Hardly speed or UX. Type a quick command on the CLI yo do any of that stuff and it's finished before you can even use you arrow keys to move between various regions of the screen and move your eyes around the work area to confirm everything and select your actions and move your gaze again to confirm the result is what you expect.
It's all about what you're used to and what you know. If you grew up in the age of the point-and-click GUI you might feel more comfortable using visual metaphors and stateful UIs for your intended actions. Others prefer to issue orders and have them obeyed without the song, dance, and lightshow.
I agree that looking around multiple panes is slow and arrow keys are slow, and that typical UI ceremony is unnecessary. But there's a benefit to seeing state changes and holding less state in your head. Kinda like `ed` versus `vim`. Someone comfortable with both editors would acknowledge vim makes some edits easier.
Of course, issuing orders still has its advantages. And yes, growing up with GUIs makes a big difference.
Thanks. That makes sense. I guess I'm just super entrenched - very comfortable with my tooling and would generally write a one-liner for something like the above.
The way I do it is a bit nuts though, and you're right, the above is much more consistent and has its advantages
With long filenames with characters like spaces, it can be easier to see them in a list, pick the ones you want, and operate on them in a GUI or TUI (same principle applies to Emacs Dired) than in a CLI. I can use the CLI and stumble around running ls multiple times and using tab completion, but the GUI or TUI can just be easier.
- power user workflows may differ from typical dev workflows. Imagine things that a point-and-click file manager solves quicker than the command-line. Example: manually organizing a bunch of .mp3s, or cleaning out misc downloads. A TUI file manager makes these tasks quicker too.
- quick directory navigation. cd is slow. There's solutions for a better cd, involving z or fzf or whatever. But a file manager should solve it too.
- a file manager, especially a two-pane view, is cognitively easier. Better UX. Example: Having a src/ pane on one side and dst/ on the other, selecting a few src/ files, then performing a copy command. You get instant visual feedback to confirm that the files appeared in dst/. Compared to ls, cp file1 file2 file3 dst/, ls dst/. I always feel the need to ls after commands because the command-line doesn't give much feedback.
tldr: speed, ux, comfort. But if you're already comfortable with your tools, I think that's the most important thing.