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.
Once upon a time I used to use https://github.com/wting/autojump as a way for my systems to help me quickly navigate to my favorite Directories Of Interest. Basically, it did (and similar tools also do) the following:
- cd is instrumented to capture directory locations each time one visits a new directory, and store them in a wee sort of database
- an alternative “cd” command is introduced that attempts to Do What I Mean. It takes the input, and sees what stored directory best matches, with a bias towards frequently used directories
autojump was written in Python, which is no grand problem; I did some poking around, and discovered a newer tool, https://github.com/clvv/fasd, which has similar capabilities, perhaps more, and has a slightly smaller footprint, being implemented in “POSIX shell,” so it can happily run on common shells such as Bash (and my fave) zsh.
So far, I have just been using the “zz” functionality that picks the seemingly-most-relevant directory. It does a fine job of this.
It is doubtless a good idea to poke some more at this; running “fasd a b c” searches recent directories for highest-relevance files containing “a” “b” and “c”, fairly successfully. Throwing multiple strings pulls up an interesting list:
cbbrowne@karush ~> fasd tmux conf
Without much effort, this locates tmux configuration files; that’s looking pretty attractive…
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.