Hacker News Reader

Comment by jonfw | Hacker News Reader

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.

View on HN

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.

If you are saying you are OK with scanning the whole filesystem every time you are looking for something that can be anywhere under /

You can specify a target directory from which to start the search.

Bookmarks you mean. Yes, in nnn you can jump to the bookmark from anywhere and then press `Alt-O` (my preferred key) to start the search.

But you know what, let me share a smarter workflow:

  find . -iname "*.mp3" -print0 | nnn -p -

Now you list all yours mp3 files in nnn, examine/play them and finally get to cherry-pick some and print them to stdout when you quit nnn.

BTW, you can also run the find within nnn and list in nnn.

I see what you did there

If you're looking for something that can be anywhere under /, then the target directory needs to be /.

Yes, that's what I intended to convey.

> endless cd-ls loop

Better to have "chpwd() { ls }" in your .zshrc as this executes ls after cd'ing to save up on your infinite amount of ls typing.

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.

Who would regularly cd into /usr/bin/?

If you only work inside messy folders with hundreds of files all the time, maybe it's time to tidy up.

There can be other frequented examples, say, ~/Pictures.

Might as well "head" the output by 10 lines or something then.

Yes, where there is a will, there is a way! :)

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.

> Separately, I have a bunch of keybindings to load sets of files into fzf for easy access.

Do you have your dotfiles available to share? That sounds really useful

I don't have dotfiles online, but many were inspired by this gist: https://gist.github.com/junegunn/8b572b8d4b5eddd8b85e5f4d40f...

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`

Thanks for sharing!

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.

nnn supports all of them BTW - find, grep, fd, ripgrep...

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?

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.

[0]: https://github.com/ranger/ranger

[1]: https://unix.stackexchange.com/questions/342064/ranger-cd-in...

> With ranger, I can even use it as an alternative to cd

cd on quit works in nnn as well... and many other file managers.

Thanks for pointing this out - here's the link, for anyone interested:

https://github.com/jarun/nnn/wiki/Basic-use-cases#configure-...

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

Yes, cd, ls, mv, cp etc. don't help much in unknown territory.

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.

[0] https://www.emacswiki.org/emacs/DiredMode

The problem with emacs-based solutions is the speed.

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.

Can't counter that given I've last used emacs years back.

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.

My response was from from emacs perspective. Here's a memory usage comparison: https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

Looks like emacs uses at least double the memory.

I guess, but I think somebody using dired would be using Emacs anyway, and dired is unlikely to be the straw that breaks the camel's back.

Completely agree.

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.

> They can be handy if you're in the middle of something else, and you need one without distraction.

Add a drop-down temrminal file manager to the mix, so you never lose your context. ;)

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

I think that workflow is available in almost any terminal file manager now.

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

nnn has an in-built batch-renamer as well as a more powerful POSIX-compliant plugin to do that.

List of features: https://github.com/jarun/nnn#features

Sometimes a GUI is faster for me, especially when I'm not 100% sure where things are or there are many files to select.

A terminal file manager has a GUI that works everywhere, including over SSH sessions (OK, technically could use X forwarding, but it's slow).

> Sometimes a GUI is faster for me, especially when I'm not 100% sure where things are or there are many files to select.

nnn takes care of these already. I don't think you would see a difference once you get used to.

Exactly. I don't understand what these grant me in terms of flexibility and workflow that bash + shell scripts do ?

Can someone who uses these tools explain ?

If your scripts do all of the following, you are already using a file manager:

https://github.com/jarun/nnn#features

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 ?

I answered to a similar question in the same thread (in response to the comment you replied to). Please take a look if that clarifies.

As a vim user, I got a good analogies, why don't you use vim over ex mode. The same applies here.

If you have to cd/ls around a lot, it's simply faster once you get used to it.

I can't speak to any of the others but Midnight Commander is the best and best maintained of the two-panel (orthodox) file managers.

Fewer keystrokes.

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)

Reply on news.ycombinator.com