Autojump makes it easy to quickly jump into any directory I've visited and then I can open my editor or Finder (file explorer) from there. Would be great if I can be inside nnn and jump to directories using autojump.
fd is very useful when I want to just directly open a file. I might be in a project's root directory and I'd want to edit a file a few levels nested. Currently I either use fd to locate the path of the file, and then copy paste it into the shell. If `fd` is combined with nnn, I can type in a few letters of the file I expect, and jump to its parent directory, with the file highlighted.
Is this workflow possible in nnn, or can it be written using its scripting?
fd: `nnn` integrates seamlessly with fzy (another blazing fast C utility).
And when you need to do a more complicated operation you're looking at a shell oneliner vs. multiple (possibly repetitive) manual steps in the UI.
If simple copying of files made up a great deal of my daily work, I'd certainly use a file manager (if I couldn't write a script to do it).
Any comparison between the two systems should stem from there: you’ve only offered half of it.
Eg getting a remote virtual disk set up in OSX’s finder is much easier than on terminal, without googling/general research, for a one-off drive. Getting 50 such disks up and going is far easier on terminal. (CLI has a better O(), but worse constant factor.)
Once the GUI reaches hundreds of actions it's no longer easy to find the functionality you're looking for.
On CLI eg I don’t remember the mkfs command for a file system, I type mkfs and hit tab twice.
It could be better though, of course.
You'll be searching (or using previous knowledge) for what you need to format it as, anyway.
In any case you are focusing too much on mkfs, I can think of plenty of other examples, many of each aren't even portable across UNIX environments.
While GUIs at least can offer navigation and visual cues as means to discover features.
Eg ffmpeg is confusing no matter what, but the cli is particularly obtuse in how options interrelate (or even the format string required for them!). A gui for ffmpeg will naturally have fewer options (less expressive), related features to an option will be grouped by windows, and might even do things like visibly disable options based on current flags set, or even a preview mode.
You could probably get by to a certain degree, when new to the program, on an ffmpeg gui for simple operations; even the most basic action of cli will be difficult just reading the options appearing by 2xtab.
There’s simply a lot more a gui can do to help the learning/interactive process than a cli can (tui is a different story: its just a gui that happens to be in your terminal, and offers the same positives/negatives that any other gui does).
[1] I mean, I know there are some tools to automate GUI tasks, like AutoHotkey, AutoIt, etc., but due to various window-related issues, they are fragile, I've heard.
Not saying that this makes CLIs superior for all uses, of course. Just better for some.
[2]:
Some time I did a survey for a neat a nice terminal fm. Trying a lot of different kinds I ended up with vifm.
Copying multiple files regularly I recommend using Python Fabric.
Always miss it. But never had the time to write it myself.
The shell in `nnn` is also a real shell with your complete env settings. So it remembers everything.
I can't think of a workflow where you are working both in the shell and the file manager when you have selection in place. It's a convenience, yes. But both are exclusive in nature.