💾 Archived View for gemini.rlamacraft.uk › techGuides › isTmuxNecessary.gmi captured on 2024-05-12 at 15:08:24. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Is tmux necessary?

I've been thinking lately about whether tmux is a necessary part of my development environment.

First a little background is in order. When developing software, I take the UNIX-is-my-IDE approach, keeping my tools as simple as possible and only deviating from what is standard when there is a very good reason for it. I use vim as my editor of choice, augmented with just a couple of plugins like FZF integration, easymotion, and Tim Pope's awesome work. I use aerc[1] as my email client, git for source control, and then a collection of short running (compiler, linter, test runner) and long running (local Web server) processes. And then tmux to manage them all.

Tmux isn't standard though. It's also fairly complex (especially the stuff with detached sessions). Because of the way it takes over the role of the terminal emulator it also requires additional overhead to scroll back and copy old output. Just feels unnecessarily complex.

Enter, job control.

Every shell has the ability to do some rudimentary multitasking using job control. The trick, which took me a few days to figure out, is to have child shell processes, suspended in the background, to isolate various command line tasks. Starting one is easy enough (this'll work in zsh and bash, I believe the command is slightly different in csh)

{ sh; } &

Replacing `sh` with your interactive shell of choice.

The trickier bit is being able to background the running child shell and return to the parent shell. ctrl-z, used whilst most long-running processes are running in the foreground, wont work here as the child shell will capture it thinking that you are doing so to perform job control within it rather than the parent. Instead the `suspend` command can be used to achieve the same thing -- which suspends the current shell, sending it to the background, and returning focus to the parent shell.

The only other small thing I've started to do is to prefix the command above with an echo statement so that when I list all of the suspended shells with `jobs` it is possible to identify them e.g.

{ echo "dev work" && sh; } &

The pros and cons

The pros are outlined above, really. It's one less dependency that I need to be productive; gives me the ability to sit down in front of any posix machine and be comfortable multitasking. It also cuts out the complexity of tmux -- I just don't need the ability to detach and reattach sessions or whatever. Finally, I can rely on my terminal emulator to provide a much cleaner way to scroll back through the command history and my OS to provide a simple copy and paste functionality, rather than tmux's clunky ctrl-[ and ctrl-] system.

The cons are fairly obvious. Job control is fairly clunky. Context switching is little more cumbersome -- having to run two shell commands rather than a single keybinding -- and it's not possible to have two shells side-by-side which I very occasionally do.

But I'm up for giving it a try.

[1] aerc

~~~

Last Updated: 2021-12-21