3 ms·

I've tried to switch to tmux a few times over the years, but the command line options and keybindings never stick in my brain. My fingers keep wanting to use th

I've tried to switch to tmux a few times over the years, but the command line options and keybindings never stick in my brain. My fingers keep wanting to use the screen options. So, I always go back. I probably should just figure out how to make screen do what I want (scrolling back in history is probably the biggest one, and I know I had figured it out in the past...but my current systems don't have it working, I don't think, or I don't remember the incantation to do it). I wish screen worked more like a normal terminal session, is what I'm trying to say, and tmux seems to be closer to that ideal without configuration or learning new ways to do things. But, my muscle memory wants screen.

sikhnerd 10y ago
Sounds like you don't use many screen keybindings either? Likely just remapping the default key binding to match screen's in your .tmux.conf gets you 90% of the way there: unbind C-b set -g prefix C-a bind C-a send-prefix fwiw, the shortcut to enter copy mode in tmux and screen is the same C-a [
- SwellJoe 10y ago
  I'd end up trying to use the wrong bindings on systems that don't have the configuration yet. I've just got too many boxes/VMs (and have too many individual users on each) and haven't gone to the trouble to setup a solution for rc files in a long time (since before my current batch of servers was deployed). Solving that problem is probably a productive use of my time.
  - ifoundthetao 10y ago
    I solved the same situation by making a git repo of my rc files. It's nice. One thing to keep in mind is to have it look for local files/scripts to source too. That way you can keep per-system tweaks out of the global runtime configuration. Also, passwords. Don't put passwords, or anything you don't want leaked in the rc repo. You could have it private, but that's not fool proof.
  - voltagex_ 10y ago
    Yep, I even had a makefile that set the right bindings for new boxes. I ended up just learning the ctrl-B binding instead.
chris_st 10y ago
I was in the same position a while back. However, thanks to this article[1] and learning a little bit about tmux behavior, I'm happily tmuxified. I recommend it. [1]: https://mutelight.org/practical-tmux https://mutelight.org/practical-tmux
- wyldfire 10y ago
  > Screen contents persisted through full-screen programs: in Screen, you lose your terminal's previous contents after leaving a full-screen program like an editor. Tmux doesn't have this problem. Does this mean I can preserve scrollback among each terminal? If so, I'll switch tomorrow morning. That's screen's biggest drawback.
  - amadeusz 10y ago
    Um, each screen window remembers it's scrollback properly? C-a [ - to enter 'scrollback' mode, and you can use arrows there. What they seem to describe is altscreen behaviour which can be disabled with "altscreen off" in .screenrc .
    - wyldfire 10y ago
      Oh, that's right. I'm so used to the terminal emulator's scrollback buffer keys I forgot that you just have to escape to get to this behavior. I suppose there's no way to have this work the way I want until/unless the terminal mode natively supported multiple sessions/screens.
shanemhansen 10y ago
Ctrl-a ESC allows you to scroll up in your history.

sikhnerd 10y ago

Sounds like you don't use many screen keybindings either? Likely just remapping the default key binding to match screen's in your .tmux.conf gets you 90% of the way there: unbind C-b set -g prefix C-a bind C-a send-prefix fwiw, the shortcut to enter copy mode in tmux and screen is the same C-a [

SwellJoe 10y ago
I'd end up trying to use the wrong bindings on systems that don't have the configuration yet. I've just got too many boxes/VMs (and have too many individual users on each) and haven't gone to the trouble to setup a solution for rc files in a long time (since before my current batch of servers was deployed). Solving that problem is probably a productive use of my time.
- ifoundthetao 10y ago
  I solved the same situation by making a git repo of my rc files. It's nice. One thing to keep in mind is to have it look for local files/scripts to source too. That way you can keep per-system tweaks out of the global runtime configuration. Also, passwords. Don't put passwords, or anything you don't want leaked in the rc repo. You could have it private, but that's not fool proof.
- voltagex_ 10y ago
  Yep, I even had a makefile that set the right bindings for new boxes. I ended up just learning the ctrl-B binding instead.

chris_st 10y ago

I was in the same position a while back. However, thanks to this article[1] and learning a little bit about tmux behavior, I'm happily tmuxified. I recommend it. [1]: https://mutelight.org/practical-tmux https://mutelight.org/practical-tmux

wyldfire 10y ago
> Screen contents persisted through full-screen programs: in Screen, you lose your terminal's previous contents after leaving a full-screen program like an editor. Tmux doesn't have this problem. Does this mean I can preserve scrollback among each terminal? If so, I'll switch tomorrow morning. That's screen's biggest drawback.
- amadeusz 10y ago
  Um, each screen window remembers it's scrollback properly? C-a [ - to enter 'scrollback' mode, and you can use arrows there. What they seem to describe is altscreen behaviour which can be disabled with "altscreen off" in .screenrc .
  - wyldfire 10y ago
    Oh, that's right. I'm so used to the terminal emulator's scrollback buffer keys I forgot that you just have to escape to get to this behavior. I suppose there's no way to have this work the way I want until/unless the terminal mode natively supported multiple sessions/screens.

shanemhansen 10y ago

Ctrl-a ESC allows you to scroll up in your history.