nnn, findable at https://github.com/jarun/nnn, is a terminal-based file manager written in Go, which claims high performance and has a pretty flexible set of functionalities including:
- Can spawn your favorite $VISUAL $EDITOR to edit files
- Bookmarks (haven’t used)
- Fuzzy searching for files
- Pin frequently used files/directories
- Mount and manage archives
- Lots of plugins https://github.com/jarun/nnn/tree/master/plugins to extend its behaviour
I have, several times, scheduled tasks (taskwarrior!) to poke some more at nnn. It seems inevitable to not go anywhere.
Why that is finally occurred to me; the reason is that my workflow that would be most relevant to this takes place inside emacs, in the Dired mode.
There are some neat things in nnn, notably the fuzzy searching, which would lend itself to somewhat more nondeterministic searches for Files Of Interest. However, the learning curve of switching to a dramatically different tool is not to my taste.
If you’re one of the vi crowd, this may be to your taste; it seems interesting. (I was tempted enough to keep it lurking in my task list for a couple months.)
I have been a longstanding user of GNU screen, a terminal multiplexor, which is loosely a terminal-oriented equivalent to an X window manager. For a fair number of years now, I have been using tmux instead; it was written more recently, starting from scratch, with BSD license, and so is somewhat smaller, perhaps faster, and leaves behind features that weren’t of much interest.
What I do with this
I commonly set up tmux sessions when I first log onto a system, and set up some sub-terminals tied to useful tasks such as:
- Command sessions – I’ll always have some terminals ready to run commands
- Log tails – if I am debugging something, I will set up a
tail -f command in a virtual terminal to watch the logs, so that I may quickly switch to that terminal and see what has recently happened
- ssh sessions for command sessions running on remote hosts (on my laptop, these will be mosh sessions
- kubernetes sessions – command sessions where the CLI environment is set up for one k8s environment or another
The awesome-tmux Github site has a whole lot of useful links to “meta-tools” for use with tmux, various of which I have found useful:
- tmuxinator allows setting up a whole tmux session complete with numerous virtual terminals connected to commands and environments
- gitmux puts git status information into the tmux status bar, which is nicer than putting it (as I have done with zsh) onto the start or end of the command line
- tmux-continuum will automatically save the state of a tmux session environment so that a complex environment may be automatically recreated. This is pretty cool as a “perhaps better than tmuxinator” thing; with tmuxinator, it’s easy to restart, but you need to add environment configuration manually to tmuxinator configuration, whereas continuum picks that up automatically. There are definitely advantages and disadvantages in both directions; tmuxinator will tend to have a “cleaner” environment, but you need to do more work to get that cleanliness.
Also playing with 3mux
3mux was inspired by tmux and by the i3 window manager; it makes more natural use of the mouse, has a claimed-more-sane set of keybindings, and claims a shorter learning curve.
I have played with it a bit; in view that I had gotten through the GNU Screen learning curve many years ago, that’s not so much something I’d account as good, and the differences have proven demerits to me. Also note that there’s lots of third party projects improving on tmux that don’t naturally automatically apply to 3mux.
I did a talk in 2015 on Screen, Tmux, Byobu, the Secret Terminal Brains!!!
See also my web page on GNU screen, which has further links about tmux and related tools.
I have been using Mosh for quite a number of years now; it is a notionally “mobile” shell that nicely supports devices with intermittent connectivity. On occasion, I have used it as an alternative protocol to ssh when using my laptops/tablets/phones to connect to shell sessions.
Its main merits (to me) are that:
- Sessions can survive even fairly long connectivity outages. The more I use tmux to manage sessions on servers, the less that matters, but it is still a useful convenience particularly with connections from my phone.
- Rather than replaying every keystroke (or every receipt of a character of a log file /bin/cat’ed to stdout), it maintains the state of the screen, so it can refresh the screen, skipping over long-irrelevant output, which is an extraordinary network performance improvement if one is browsing server logs…
Curiously, every so often, and this is why I thought to blog about this, I periodically still get forwarded notifications that people continue to report on issue #98 which I helpt report on back in 2012. I was a bit nonplussed this week to notice another update to this that indicates that people are continue to use (or at least reference) my circa-2012 workaround to issues getting Mosh to connect across systems with slightly differing ideas of UTF-8. I suppose I should be proud that my workaround (which is to explicitly pass LANG and LC_ALL values to mosh client and server programs) continues to seem a relevant solution. I have shell scripts lurking around that are almost 8 years old for doing mosh connections in my local environments that use this. I am, however, a wee bit disappointed that nearly 8 years of further development hasn’t made it unnecessary to tweak these environment aspects.
It is a somewhat happy thing that Mosh’s code base is stable enough (and I note it’s included in numerous Linux and BSD distributions, as well as having support in Android apps such as JuiceSSH) that it is, of late, seeing new commits only every few months.