
Nnn – a terminal file manager for programmers - max_sendfeld
https://github.com/jarun/nnn
======
dang
Show HN is for sharing your own personal work. We got a complaint saying that
this is not the submitter's work, so I've taken Show HN out of the title.

Posting as a Show HN something you didn't create is effectively taking credit
for someone else's work, so please don't do that!

Please read the rules:
[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html).

~~~
apjana
Hi, author of `nnn` here. I didn't submit it but I am actively responding to
the comments and it is actually helping me to get feedback and feature ideas.

I am grateful OP posted it. Thanks for fixing the title.

~~~
dang
Thanks, that's good to hear.

------
throwaway053934
A lot of good features in nnn. Unfortunately, for me, the huge deal breaker is
the (sorry, but I have to say it) _terrible_ choices for one of the most
important hotkey-functionality combinations.

I am not talking about some rarely used keys/functions, but the problem lies
at the very core of the experience: the simple hjkl, vim-style navigation.

You see, as in vim, k/j ('up'/'down') obviously move up/down in the list of
dirs/files. h ('left') moves up the directory hierarchy ('Parent dir' as nnn's
help aptly describes the function.) Of course, now l ('right') moves down the
directory hierarchy: IF you are sitting with the highlight on a DIRECTORY
entry, obviously if moves down into that directory.

But here is the kicker: what if you have as your current highlight something
OTHER than a directory, that is a FILE ?

It OPENS the file. (The open operation is done through xdg-open, so whatever
that is configured to recognize) If xdg-open is not configured defensively, in
the case when the file is executable it runs the program. Or if the file has
some associated program, it is launched with the file as an argument. (this
was happening even on my machine, and I have a relatively conservative xdg-
open config) At the minimum it launches an editor, opening the file in
read/WRITE. In nnn's help, listed among the keys activating this 'Open
file/enter dir' is the <Return> key, in addition to the usual move right keys
(so 'l' and right arrow). A clear expression that in the authors intention
those keys have equivalent functionality.

So imagine you're browsing around the file system as fast as your fingers and
eyes allow (after, that's the beauty of the fast text/ncurses interfaces,
yes?). You just want to examine stuff, look at files, poke into
configurations, maybe for a archive you just downloaded. Archive that might or
might not have executable stuff and/or potentially harmful things. You've
located the dir path you want to go into, you dive in and before you realize
you need to hit the brakes on that 'l' key, you end up moveing RIGHT on
SOMETHING (it happened so fast you're not even sure what it was), and that
SOMETHING was executed/loaded, now some application is opened, and on top of
that you were continuing to type so that application receives your keys and
does who-knows-what (well, depending on what was launched).

WTF ??? The first time it happened, I could not believe such a UI design
decision: mixing NAVIGATION and OPEN operations on the SAME KEY. OPEN is a
sensitive, potentially disruptive operation: there SHOULD be some minimal
friction provided in the interface before one is allowed to proceed.

It moved this nnn from potentially one my favorite tools, into a totally
love/hate relationship. Yes, "love" because indeed it does some things well.
But the mistake of this RIGHT/OPEN snafu is enough to more than cancel any
other qualities.

~~~
ubercow13
That's the way it works in most file managers... Usually a click would open a
directory or a file just the same

~~~
throwaway053934
First of all: when using a _mouse_ 'a click would open a directory or a file
just the same'. A mouse/trackpad has pretty much _one button_ (or equivalent)
dedicated to interaction, so it is expected to overload some functions on it.
Besides, "navigation" with the mouse is a different thing: you don't need to
"move" the selection so opening is a clear voluntary decision, decoupled from
navigation.

But focusing back on _keyboard_ operation... It is true that many text based
file managers do this 'open file on right navigation move'. In my opinion that
doesn't make it right: I personally consider a bad thing that can lead to
startling, unnecessary and potentially sensitive application launches; a
separation between movement (hjkl, arrows) and opening (obvious choice here,
<Return>) is a sensible design.

Another point of view: the unwanted file-open-by-mistake situations are a form
of involuntary file previews. As nnn's own 'design considerations' state [0],
previews are to be avoided: "previewing ... is a wastage", potential
"slow/faulty ... access makes the experience very painful" and "Users should
see only what they _explicitly_ want to see".

Lastly, there is an important aspect that mitigates the problem for 'most file
managers': customization.

Here's a quick glance at the players in this text-fm arena:

\- ranger and vifm, the larger managers: a cursory look in their help/configs
hints that they can be heavily customized \- out of the box ranger displays a
preview of the selected file; that acts a big visual hint that you don't need
to 'navigate' further; however I agree that default previews are bad \- ranger
and vifm remember the position along the path, so you don't get shunted moving
back down \- noice has about the same behavior as nnn (nnn was forked from
it), but at least it has a standard suckless style config.h header allowing
customization by recompiling \- speaking of suckless style, a last resort
solution is to do just that with nnn, making your own fork: its header largely
keeps the structure of the original

And here are examples that work more along the lines I prefer:

\- rover has the best behavior IMO: it can be similarly configured using
environment variables, but by default it uses hjkl simply for navigation and
NOTHING ELSE; it has separate, dedicated keys for open, preview or other
things \- midnight commander has the same separation: arrows (actually just
up/down) strictly for navigation (in local dir ONLY, no less); explicit
directory navigation and opening with <Return>; there is no implicit 'file
open'

[0] [https://github.com/jarun/nnn/wiki/nnn-design-
considerations](https://github.com/jarun/nnn/wiki/nnn-design-considerations)

------
rsync
I do not use a terminal based file manager - I find that a better workflow for
me is to use sshfs to create a local mount on my laptop and then just use the
Finder to browse ... which gives me preview, etc.

HOWEVER, there is a specific use-case - renaming a bunch of files in a
directory - where I do use a "file manager" and that file manager is
'vimv'.[1]

vimv is a very simple tool - you run vimv in a directory and suddenly the vi
editor opens up with the contents of that directory. You then use the vi
editor to edit the filenames any way you like. Upon :wq, the files in that
directory are renamed.

Very useful - and in many cases, much faster than crafting a sed/awk one liner
to do the renaming (especially if some of the renaming is arbitrary or
random).

[1] [https://github.com/thameera/vimv](https://github.com/thameera/vimv)

~~~
philsnow
Obligatory mention of emacs wdired-mode, which sounds very similar. I mention
it because I used emacs for almost a decade before noticing that there's a
wdired mode as well as dired mode.

~~~
kqr
There also sunrise mode, which combines (w)dired with ortodox file managers.
Easily one of the best ways to deal with files. Particularly in combination
with Tramp...

~~~
jskulski
What is sunrise mode? Are you referring to
[https://www.emacswiki.org/emacs/Sunrise_Commander](https://www.emacswiki.org/emacs/Sunrise_Commander)
?

------
opan
The search is extremely cool and fun to use. Directories all seem to load very
very quickly. It's got vidir integration, giving it bulk-renaming. I wasn't
familiar with vidir, but the ":bulkrename" command in ranger was my favorite
part of it. After a few minutes of poking around with nnn, I ended up
installing it on all my machines. The only weird thing I noticed was that I
couldn't find a straight-forward way to delete files. The first thing I came
up with was to hit ! to go into a shell and then just use rm. Not sure if I
was missing something or if this was deliberate to make sure you don't
accidentally delete files.

~~~
apjana
In the just-released version 2.1, you can just select a file and press `^X` to
delete it.

~~~
Crontab
I am testing Nnn via Homebrew and I am also missing the ability to delete. The
in-program help lists '^X' as Quit.

Is anyone else who installed via Homebrew able to delete?

~~~
apjana
The DEL key wasn't handled in rename prompt. The fix is available on master
branch.

~~~
Crontab
Just noticed you mentioned 2.1 and Homebrew installed 2.0. That is probably
why I am not seeing it.

~~~
apjana
It's not available in 2.1 either. Last night a user reported this after
release of 2.1. :)

------
yorhel
This looks incredibly cool, I love the speed and minimalism. It doesn't seem
as configurable and feature-packed as vifm[1], so I'll probably stick with
that, but it certainly fills a good niche.

> nnn vs. ncdu memory usage in disk usage analyzer mode (400K files on disk):

I assume that's because nnn isn't keeping the entire directory structure in
memory, which means that browsing to a subdirectory involves rescanning the
entire directory. That's a fair trade-off, but an unfair comparison.

1\. [https://vifm.info/](https://vifm.info/) \- I'm surprised this hasn't been
mentioned yet in this thread.

~~~
apjana
Author of `nnn` here. Thanks for the appreciation.

Please let us know what you like in vifm which isn't available in `nnn` and we
will consider the features. However, I must say the last thing we want to see
in `nnn` is feature bloat. You can extend it as you wish through scripts which
`nnn` supports in any number.

No, `nnn` scans the complete dir tree otherwise du won't work. It rescans
because data on disks keep changing e.g. on our server where 17 people run
VMs. It can be easily changed to static but the rescan is very fast and users
specifically asked for it. The memory usage is less because `nnn` uses much
less memory for all operations in general.

~~~
yorhel
I appreciate your work, but you're not being very honest with your claims.

nnn is _not_ keeping information about 400K files in memory in that benchmark.
As a result, the rescan is necessary when changing directory. The rescan may
be fast in many cases and in some cases it may even be what you'd want, but I
can also name many cases where you certainly won't want it (large NFS mounts
being one example).

Sorry for the pedantry. I spent a fair amount of time optimizing ncdu's memory
usage, so I tend to have an opinion on this topic. :)

~~~
apjana
I think we are saying the same thing in different lingo. I am trying to say,
you do not need to store it if you can have fast rescans.

Coming to memory usage, if you store the sizes of every file you need 400K * 8
bytes = ~3 MB.

Now `ncdu` uses ~60 MB and `nnn` uses ~3.5 MB. How do you justify that huge
gap?

> but you're not being very honest with your claims

No, I am completely honest within the limits of my technical understanding.
Your tool uses 57 MB extra which would be considerable on a Raspberry Pi model
B. To an end user, it's not important how a tool shows the du of `/`, what's
important is - is the tool reasonable or not? I don't know how `ncdu` manages
the memory within, I took a snapshot of the memory usage at `/`.

In fact, now I have questions about your very first line beginning with `This
looks incredibly cool` and then the comparisons of it with different utilities
in negative light. (I must be a fool realizing it now, I should have seen it
coming.)

~~~
propa
Your calculation (`400K * 8 bytes = ~3 MB`) is way off. What would be the
point of storing only the size? You need to map it back to the file.

60MB gives you about 150 bytes for file path or file name and its size, which
sounds plausible.

~~~
apjana
I can think of at least 3 possible algorithms to use much much less memory
even with a static snapshot of the complete subtree. And all of them are
broken because the filesystem is supposed to stay online and change. It's
realistically useful to scan an external disk to find the largest file etc.,
but not accurate on a live server, a desktop with several ongoing downloads,
video multiplexing etc.

~~~
propa
Earlier in the thread you suggested that it's hard to justify ncdu using 60MB
while it takes only 3.5MB to store 400K * 8 bytes numbers. The number you came
up with is just silly and overlooks actual complexity of the problem.

Given that you are making an implicit judgement about the other program, don't
be sloppy with your estimates.

~~~
apjana
> don't be sloppy with your estimates

I'm not. You can, and I'm sure eventually you will arrive very close to the
approximation.

I'd been a big time fan of `ncdu` for years and even wrote in an e-journal
about it once. Maybe that's why the sharp adjectives became more difficult to
digest. Anyway, good luck!

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

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

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

~~~
marmaduke
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.

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

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

~~~
pjmlp
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.

------
zmix
Very nice! I often end up running MidnightCommander but this would be enough
in most cases. I really like the idea!

~~~
BozeWolf
+1 for mc! Using it for almost 2 decades now. First on linux, now on macOS.

~~~
atmosx
I use it on my RPis, but now I am going to try nnn if it runs on ARM. MC is
legendary though and the fact that supports multiple transfer protocols is a
very helpful.

~~~
apjana
`nnn` integrates with lftp. I have added a wiki page on how to automate
transfers or copy selection easily.

------
AnaniasAnanas
My friends have been using it for a few days and they seemed quite happy with
it. The only thing that stops me from using it is that I need thumbnails, so I
am stuck with spacefm for now.

~~~
kakarot
Any particular reason spacefm stands out to you over the rest?

~~~
AnaniasAnanas
I tried multiple file managers in the past. Dolphin is really good but it has
a lot of KDE dependencies. Thunar had quite a few bugs that annoyed me, for
example when I configured backspace to go to the parent directory it activated
even when I was editing the path. In the past I used to use Nautilus until it
replaced the quick search feature with a recursive search thing, in addition
to removing the ability to change keybinds, plus I kept getting crashes and
getting a lot of lag when visiting a directory with 10k+ images with it later
on. Most of the other file managers that I tried either did not have
thumbnails or they did not support tabs.

Spacefm does not have any of the above issues, which is why I am currently
using it.

~~~
kakarot
I use Thunar and avoid Nautilus pretty much for the same reasons. I like
Thunar because it keeps things simple, and I have bash for anything complex,
which a lot of my file operations tend to be. I'll check out spacefm and see
what I think, thanks for the recommendation.

------
thibran
Emacs Dired + Tramp -> no need for any other tool.

One super awesome Dired feature is C-x C-q to edit a folder like a file (all
Emacs commands work here, like macros which are easier & faster to get right
than most shell commands). To save your changes after editing, press C-c C-c.

~~~
earthscienceman
I would love to hear other dired features that people use. I'm just now
getting a comprehensive understanding of how great dired is.

~~~
atmosx
Does it support file transfer over ftp, sftp, s3, etc?

~~~
ISO-morphism
Yes, that's where tramp comes in, although s3 might need a separate plugin.

For me the best part of dired is "do-what-i-mean" mode, dired-dwim. You
basically get the output of `ls -la` and edit it as a text file. When you
save, dired figures out changed names/permission bits/etc and does what you
mean to those files.

------
chmln
Lack of file previews makes it a deal breaker. Ranger is a bit slower, but it
does so much more.

~~~
atmoz
I agree. Would be very nice if this was an option at least (that could be
turned on by configuration). On the design considerations [1] they state:

> Previewing large files on selection is a wastage of processing power and
> time. A slow/faulty disk or over the network access makes the experience
> very painful.

You only need the first lines of the file, not the whole file, so this
argument is not valid.

> It's also a risk to privacy and confidentiality. Users should see only what
> they explicitly want to see.

Not valid if preview is off by default. A hotkey could toggle preview mode.

Yes, you can open each file in a pager. Exit the pager, go to the next file
and repeat. That is slow and painful. Being able to browse a code repository
with file preview is the main reason I will probably not use this and stick
with ranger. It's a deal breaker for me.

I really like that it's fast (I've tried using ranger on the USB Armory – it
was very slow), and if preview was added as an option I would seriously
reconsider.

[1]: [https://github.com/jarun/nnn/wiki/nnn-design-
considerations](https://github.com/jarun/nnn/wiki/nnn-design-considerations)

------
jankotek
> nnn is probably the fastest and most resource-sensitive file manager you
> have ever used.

Volkov Commander is written in assembler, binary has 32KB with zero deps,
memory requirements far bellow 1MB. It has better UI and more features.

~~~
apjana
It's for DOS and is a shareware.

> better UI

I doubt that from the screenshots. But it's a personal preference.

------
nderjung
How does this compare to
[https://github.com/ranger/ranger](https://github.com/ranger/ranger) ?

~~~
agumonkey
more minimalist, smaller, a tiny bit more responsive. Probably a lot less
capable since ranger seems quite featured.

~~~
apjana
In fact every operation would be slower in an interpreted or scripting
language. It becomes evident on a Raspberry Pi, Linux subsystem for Windows
(even on i7, yes), when opened within vim as a file chooser, or on Termux env
(Android). `nnn` finds its users in all these constrained environments.

Also `nnn` is not a feature by feature replacement for ranger. The last thing
we want is a feature bloat. And we are very open to useful feature requests.
Let us know if you are missing something.

~~~
agumonkey
We really should all develop on slow machines.

~~~
apjana
develop > test

~~~
agumonkey
that too. I did so for website. If it loads fast and render neat under elinks
Ill keep it.

------
zestyping
Why doesn't nnn remember where you are in a directory? It seems natural to me
that "hl" should preserve your state, e.g. "hhll" should take you back to the
same place you were in.

Was it an intentional design choice to make "l" put you back on the first
entry in the directory? Why?

~~~
apjana
Yes, we didn't want to remember the last file selected in every directory
visited. In other words, it's like remembering the state of every directory
visited. `nnn` selects the parent dir when you come out of a child dir.

~~~
nemetroid
You don't need to remember the state of _every_ directory visited. The
functionality GP is asking for is similar to the forward button in the web
browser. I.e., if you're starting in `/a/b/c/d`, to be able to go

    
    
      /a/b/c/d -> /a/b/c -> /a/b -> /a/b/c -> /a/b/c/d
    

However, if you instead go into `/a/b/x` after the first two steps, the
"forward history" would be lost.

~~~
apjana
Ah, OK! I thought every file in every dir. To do this you would have to
remember each absolute path which is 4K max per path (or allocate dynamically
and free every time when changed). We try to keep `nnn` light on memory.

I must admit this is the first time I am hearing it's a problem. Probably
because of the abundance of other navigation options available in `nnn`.

------
YeGoblynQueenne
How is this better than Midnight Commander?

~~~
apjana
Author of `nnn` here. I'm not very familiar with MC (sorry about that) as I
don't use it so can't provide a meaningful/unbiased feature comparison.
However, you can find the list of features in `nnn` here:
[https://github.com/jarun/nnn#features](https://github.com/jarun/nnn#features)

In addition, last night I added a vim plugin to use `nnn` as a file picker
within vim.

~~~
YeGoblynQueenne
Thank you for your reply, and no worries for not being familiar with mc. I
addressed the question generally to HN, hoping for some feedaback from anyone
who happens to have used both.

EDIT: One nice thing that mc has is that it lets you open a remote shell via
ssh. I use that a lot (I find sc syntax a big pain) so I'd miss that a lot in
nnn. Sorry if that feature is included and I failed to spot it.

~~~
apjana
> Sorry if that feature is included and I failed to spot it.

Don't be, it's not in yet. It's on the ToDo list. I would really appreciate a
PR.

~~~
YeGoblynQueenne
A PR? Well, I wouldn't completely write it out, but my C is really rusty and I
am being buried under a ton of stuff I'm expected to do (I'm doing a PhD, so I
basically have no free time).

Is it just you on this project?

~~~
apjana
It was for anyone who reads the comment.

------
halayli
Reminded me of xtree gold

[https://en.wikipedia.org/wiki/XTree](https://en.wikipedia.org/wiki/XTree)

------
IronBacon
You would have my attention if it could rename files like I'm used (on Emacs)
with Dired, specifically the Wdired mode... ^__^;

~~~
apjana
`nnn` supports in-place file renaming. It also comes with `vidir` integration.

~~~
IronBacon
Briefly reading at the description vidir seems similar to Emacs' Wdired and I
suppose it's an useful and valid choice, but I've decided long time ago that
for me Vi/Vim is an hard pass... ^__^

------
akho
Why _for programmers_? What secret features support programming in particular?

~~~
mynegation
I see it as using commands vs direct manipulation, keyboard vs mouse, and - as
a result - prioritizing efficiency at the expense of slower learning curve.
Pretty much like vim vs notepad.

------
nmstoker
Works great in Termux on the Gemini. Plus there's a decent man page

~~~
apjana
Thanks for the appreciation! I myself have the habit of using `nnn` on Termux.

------
Schiphol
Does anyone who has used both nnn and ranger (the one I use, and am very happy
with) care to explain what are the selling points of that fm compared to this
one?

~~~
O_H_E
Check other threads and replies above

------
app4soft
How launch executable file from _nnn_? For example:

    
    
      > 2018-11-15 09:44   167.8M* Krita-4.1.5-x86_64.AppImage*

~~~
apjana
There was a feature to run executable scripts in `noice` (on enter) but it was
dropped in `nnn` as potentially dangerous. At this point you can spawn a
subshell and launch it manually.

------
ubercow13
Is there any way to remap the key bindings?

~~~
apjana
Not without re-compiling.

~~~
ubercow13
Thanks. So it's not much use for non-qwerty'ers as is, I'll have a look at
patching it.

~~~
apjana
For several operations, there are multiple keybinds. But I can think of
something interesting. If you can come up with a keybind profile for non-
querty, we can have a separate config for that set.

------
svilen_dobrev
i'm stuck with long-ago-forked version of vfu [https://github.com/cade-vs/vfu-
dist](https://github.com/cade-vs/vfu-dist) Works well, as old-school as it may
look.

------
upofadown
Anyone have any idea of what I am supposed to use as a file opener on OpenBSD?

~~~
apjana
If you can confirm please share so I can update the program to use the default
opener on OpenBSD.

I think it might be open(1):
[https://man.openbsd.org/file.1](https://man.openbsd.org/file.1)

same as in iOS. But i need the confirmation before making the change. Please
raise an issue in the project page for the same.

------
chemicalnovae
Any chance this has/might get support for Windows natively?

~~~
apjana
`nnn` needs ncurses. AFAIK, it's not available on Windows yet. I use it daily
on Linux subsystem for Windows and it supports Cygwin.

~~~
chemicalnovae
Excellent point, thanks for the reply, I'll give it a spin on WSL.

~~~
apjana
Have fun!

------
fiatjaf
Is there a browser-based file manager somewhere?

~~~
dredmorbius
Local or remote?

Konqueror and w3m are both web-aware local file managers.

------
sjapkee
Still have not done anything better than mc.

~~~
apjana
Does mc have a navigate as you type mode? Just curious.

------
WeAreGoingIn
Recommend vifm or why not tmux which is very configurable.

~~~
apjana
... and much much slower, yes.

I see you vouching around for alternatives in every comment thread here. No
issues. But please explain what you are seeing in other utilities that's
missing in `nnn`? I would be repeating myself, but we are very open to
reasonable feature requests.

~~~
WeAreGoingIn
Done that in main thread about vifm above.

Sorry, but my comments were invincible for long time than suddenly appeared.
Thought it was something wrong then all comments was visible. Hard to know if
you don’t know HN comment system.

~~~
apjana
I didn't realize that. Thanks for the note!

