Nohup

Right, let’s talk about the part of tmux that will make you feel like a wizard instead of a button-masher: key bindings and the .tmux.conf file. This is where you stop fighting the defaults and start bending tmux to your will. The out-of-the-box key bindings are… fine. For a 1990s text editor. The prefix key (Ctrl-b by default) is the main culprit. It’s a pinky-stretching, RSI-inducing abomination that was clearly chosen by someone who has never had to type Ctrl-b a hundred times in an hour. We’ll fix that first.

Right, let’s talk about tmux. You’re probably used to having a dozen terminal tabs open, frantically cd-ing between them, and then your SSH connection drops or your laptop decides it’s time for an unscheduled reboot. Poof. Everything’s gone. Your train of thought, that half-written command, the logs you were tailing—all of it, vaporized. It’s a special kind of digital heartbreak. tmux is the cure for this. It’s not just a terminal multiplexer; it’s a session saver. It runs on a remote server, completely independent of your local terminal emulator or SSH connection. Your work isn’t tied to a single window or a flaky network. It persists. You can detach from it, go home, reconnect, and it’s all exactly as you left it. It’s the closest thing to time travel we have in the terminal.

Alright, let’s talk about screen. It’s the venerable old guard of terminal multiplexers, the application that kept our forebears’ long-running processes alive through dial-up dropouts and ssh session timeouts. It’s powerful, it’s ubiquitous (it’s probably already installed on that remote server you’re SSH’d into), and its default configuration is a user interface crime scene. We’re going to conquer it, because sometimes you don’t have a choice, and honestly, knowing screen is like knowing how to drive a manual transmission—it gives you a deeper understanding of the machine.

Right, so you’ve started a long-running process in your terminal, something like a big database backup or a model training script. You’re about to log out for the day, but you can’t just Ctrl+C it. That would be like burning down the bakery because your bread’s still in the oven. So you do the sensible thing: you background it with Ctrl+Z and then type bg. Perfect. It’s now happily running in the background, and you can see it when you type jobs.

Right, so you want to run a command and then log out. Maybe it’s a massive database dump, a long-running scientific simulation, or a script that’s deploying your entire application. You’re not about to sit there staring at a terminal for the next six hours. You have things to do. A life to live. Or at least, other terminals to open. You might think you can just start the process and close your laptop. Don’t. The moment your shell session ends—whether you log out, your SSH connection drops, or you simply close the terminal window—it sends a hangup signal (SIGHUP) to every single process it started. This is essentially the shell’s way of saying, “Clean up, kids, we’re going home.” And your precious long-running job will be unceremoniously terminated.

Right, let’s talk about what happens when you get a little too trigger-happy with Enter and your terminal session starts to resemble a war zone. You’ve launched vim, then top, then a ping that just won’t quit, and now you’re staring at a frozen prompt, wondering how to get back to your editor without killing everything. This is where shell job control comes in. It’s the built-in process manager you didn’t know you had, and it’s about to become your best friend.

Right, so you’ve run a command in your terminal and it’s just sitting there, hanging. Maybe it’s a long-running process, or you just need that shell back. Your first instinct might be to open a new terminal tab. Don’t. That’s like getting up to answer the front door by building a whole new house. The & operator is the elegant, built-in way to get your prompt back without closing shop.