Hacker News Reader

Comment by p4bl0 | Hacker News Reader

Every time I see interesting file managers it makes me want to try and like them but I always end up abandoning them after either a few minutes or a few hours. I don't know why. I'm quite sure I could be more productive using a file manager, even a graphical one. But it's been more than ten years that the only file manager I actually use is Bash and the GNU coreutils.

View on HN

Author of `nnn` here. It would really help if you let us know what you are looking for in a file manager. `nnn` is under active development for more than a year now and we are very open to constructive feedback and feature requests.

I actually don't know what I'm looking for. I'm quite happy without one. It just feels strange as file managers seems to be most people main entry point to their computer.

two of my most used shell commands are "j" (https://github.com/wting/autojump) and "fd" (https://github.com/sharkdp/fd)

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?

autojump: `nnn` comes with bookmarks for frequently visited dirs. You can look up the list anytime.

fd: `nnn` integrates seamlessly with fzy (another blazing fast C utility).

Moving or copying files a single time might be a bit faster using a GUI (or TUI). But when you factor in starting the file manager and navigating to the right place, it's not a big difference.

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).

The primary benefit of any GUI over a functionally equivalent CLI is the improved discoverability, especially for rare, one-off tasks. CLIs over GuI primarily offers better repetition.

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.)

I somewhat disagree. Yes, if the GUI has five possible actions and you're only familiar with one of them, it's much easier to learn to do the other four things with the GUI. But it's tedious to do something the GUI wasn't designed for.

Once the GUI reaches hundreds of actions it's no longer easy to find the functionality you're looking for.

I disagree partly here: hitting tab twice in a shell usually lists available commands, possibly with some prefix. A GUI has the advantage of context, in that eg menu items of the disk utility make sense as you know they’ll be some operation on disks.

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.

That is the problem right there, you need to know mkfs exists to start with.

apropos file system

You'll be searching (or using previous knowledge) for what you need to format it as, anyway.

Well one needs to know the Disk Utility exists as well, or disk management thingy in Windows.

Sure, but that is available on a simple right mouse click on the device.

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.

One issue is that cli apps expect a man page to be available, and that you’ll be willing to read it, so options by name alone tend to be more obtuse. Better if you already know it, worse when you dont.

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).

A major issue with GUIs is that they are not scriptable [1], at least in the way CLIs are, like with a bash-like shell and all the stuff of the Unix philosophy [2] (I/O redirection, pipelines, wildcards, other Unix special characters that expand to, or mean, something (all of which you can use in your command pipelines).

[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]:

http://www.catb.org/esr/writings/taoup/html/ch01s06.html

http://www.catb.org/esr/writings/taoup/html/ch01s08.html

I am surprised how fast I have become when using Double Commander. I really needed to learn the keyboard shortcuts, but that payed off. It is really made for keyboard control, not mouse based interaction. Seemingly minor details like searching by typing selection being a toggle (space bar) help me a lot.

Very occasionally I use ranger to explore directories whose contents I've forgotten; but it is so infrequent that I'm often halfway through exploring with the shell before I remember it is better and faster with ranger

I agree, after 20 years end up with Bash and binutils.

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.

I always feel the need to have an ncurses based sql database explorer. With list/search/add/edit/delete utilities.

Always miss it. But never had the time to write it myself.

maybe try visidata (http://visidata.org), it handles sqlite and postgres among others. But personally I've only used it for csv/tsv/excel files, it handles them beautifully, with vim-style bindings.

Use midnight commander. It has the command line embedded in it, so you can still use all your shell wizardry. You get the best of both worlds.

You can fallback to the subshell in `nnn` with `!` or `^]`.

In case of mc, ^O switches to same background shell, even from editor. So, variables, functions, and command history is same. Moreover, I can run command in shell and return to mc or mcedit to continue work when shell command still works (with limitation that current working dir will not follow selection in mc). It feels like real shell, not a subshell.

In `nnn` selection works seamlessly between multiple instances.

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.

Will the subshell have all your shell aliases?

Yes.

Look into ranger. I occasionally use it to quickly look at file contents. It's a nice thing to use for 10 seconds a few times a week

I can recommend ranger, however I am not consistent with it.

If you're open for a graphical option, try "gentoo" (not the distro, the GTK+ file manager).

Disclaimer: I wrote it.

Reply on news.ycombinator.com