Show HN: tmuxp – session manager for tmux | Hacker News Reader

Show HN: tmuxp – session manager for tmux

tmuxp.git-pull.com

109 pointstony38 comments

I've mentioned this before but will mention my setup again because I think it's so great :)

ITerm has native TMux integration so you don't have to re-learn how to use TMux terminal (ex. copy and paste work differently, etc). I used to use Mosh + TMux for super durable connections and that worked beautifully. Unfortunately Mosh doesn't play well with ITerm's native integration so you can achieve a poor man's Mosh by using http://www.harding.motd.ca/autossh/.

All-together it looks something like this: Open iTerm. autossh -t myRemoteHost "tmux -CC -A"

(Of course I have an alias for this)

Nice setup but I think "TMux" is spelled "tmux".

The main reason why I learned tmux was so I can ssh into any server and use what I already know to work productively while having a durable session that doesn't break when the connection gets flakey.

Learning tmux and it's default bindings is a very good skill too have

ITerm's integration allows you to ssh into any server and start interactive mode. Is there something I'm missing?

This is the exact reason I continue to use Screen. It is much more widely available on the boxes I use (and possibly in general) than tmux.

Nice idea but iterm doesn't run on Linux. Shame.

tmux control mode is available from tmux on Linux as well.

For some reason there doesn't seem to be support for it on Linux terminals though: http://unix.stackexchange.com/questions/189805/what-terminal...

Strange. I have found using iTerm through tmux to be very liberating and easy.

I used to have tmux configuration with right display settings, shortcuts etc. Then I, too, discovered iTerm's tmux support. I have forgotten all I knew about tmux, I just use iTerm and it just works.

Autossh for automatic reconnection would be splendid. Unfortunately, it did not work iTerm 3.1 beta 2 with autossh 1.4e. I'll have to check again when 3.1 gets out of beta. Though restarting connections doesn't happen that often, fortunately.

When working through mobile network I sometimes get latencies that makes me wish for what Mosh can do. Hopefully somebody figures out what magic is needed for shells and terminals to communicate between themselves. All of these solutions, while working, do have some hacky feel to them. Mind you, this is a hard problem due to long legacy of Unix tools.

Also, for my version of autossh and Ubuntu server needed this incantation: autossh -M 5055 -t SERVER "tmux -CC attach"

Having used tmux for a while, I got quite comfortable with it's keybindings. Using the iterm integration offers a nicer UI, but it feels like a real step back interms of keyboard shortcuts.

Is there a way to use the iterm integration but keep the tmux keyboard config? I did not find anything...

Can someone explain the advantage of this (or tmuxinator, etc) over launching a bash script or custom per-session tmux config file that sets up windows and panes and launches the right apps?

I see there's a --freeze option that saves the layout of the current session but that's a partial solution as it can't really freeze and restore the state of the applications running in the terminal windows (which is a deal breaker for me as I need to be working in a "blessed" environment for Android development with certain env variables, etc set up by a script).

Side note: tmux has an annoying misfeature that panes can't be named nor does their numbering stay stable. It's a bit tricky to programmatically set up a bunch of panes (can't do `tmux split-window -t mysession:mywindow.mypane` because mypane will change with every split) in the correct layout. So to get a specific layout, you need to do all your splits in a specific order. I did read somewhere that naming panes is a feature under development, though.

The declarative nature of having a YAML/JSON config that consistently abstracts out the commands you'd make. It prevents the mistakes and repetition scripting tmux entails.

In addition, there's no need to worry about shell scripting portability across systems. I personally use macOS, Linux and BSDs, so I have to take extra time to ensure my scripts work on machines without Bash.

For some shortcuts, tips, and tricks on tmux, I have a section in a book I've recently published at https://leanpub.com/the-tao-of-tmux/read#scripting-tmux. It's freely available online. It covers command aliases, pattern matching, targets and formats.

> Side note: tmux has an annoying misfeature that panes can't be named nor does their numbering stay stable. It's a bit tricky to programmatically set up a bunch of panes (can't do `tmux split-window -t mysession:mywindow.mypane`

The internal pane_id stays the same. If you're using a library like libtmux (https://libtmux.git-pull.com), you can keep reference to the pane after split-window commands and stuff.

> So to get a specific layout, you need to do all your splits in a specific order.

Yes, this is one of the reason tools like tmuxp, tmuxinator and tmuxomatic exist.

tmuxp goes the extra mile and has integration tests across a matrix of tmux versions to assure complex configurations produce the intended result upon loading a session. (https://github.com/tony/tmuxp/tree/master/tests)

Writing those tests took time, but were highly worth it when minor changes in the behavior of tmux popped up across versions.

This and every other tmux manager.. written in ruby or some other high level lang.. idiotism. These should be C or Go or whatever lang without shitloads installation required for these.

Think for a second who the target market is: developers. Many, many developers nowadays have a Python or Ruby environment already set up, or both. I'm not even a developer and I run Python, Ruby, and Node utilities without much added complexity.

Plus, the whole point of a decent package manager is to simplify the "shitloads installation" process. Then again the situation might be better on Mac, where Homebrew installations have maybe one or two dependencies, then on your typical Linux distro which will install dozens of libraries separate packages. But then the difference is purely psychological, and that's why commands like "yum autoremove" exist.

Haha... I understand that feeling... which is why I wrote one in Go.

https://github.com/davinche/gmux

neat, I will look into this!

Personally I use https://github.com/tmux-plugins/tmux-resurrect

It's not as configurable, but doesn't really need much configuration.

I use the same but doesn't it just save only one session? This one seems to have multiple sessions based on the config that you pass.

Use tmux-resurrect as well. But I might give this one a go. Depending on the type of code that I am working on, I like to use slightly different tmux layouts, and it would be nice to use the per project capabilities.

I use tmux-resurrect too. Saves just one session, but does the job for me.

I'm often skeptical about ruby/python wrappers but I've been using tmuxp the last year and have no complaints.

I never configure it. I have three sessions configured that I start, whether at work or at home.

Shells - Irssi, vim, bash.

SSH - All my ssh

Vim - My development (inside I then use vim tabs for different areas of a project)

My experience from configuring tmuxp in Yaml is not overall good, it felt clunky and immature. But like I said, I never touch it anymore. It just works.

My preferred tmux session manager : https://github.com/oxidane/tmuxomatic Has the easiest configuration I've seen, I can only advise to try it out!

I keep meaning to change to tmux, but for some reason I still stick to screen. I know tmux is so much better, but I still find all the features I need in screen, and it happens to be installed on most hosts I am using.

If you're happy with `screen` then there's little point changing. The tech industry can often have an air of elitism with regards to tools we're told we "should" use. While sometimes there will be reasonable arguments for or against specific tools, usually the overriding deciding factor is just personal preference.

That all said, I do completely relate to your "[screen] happens to be installed on most hosts" point. That's also the main reason I've never switched to zsh over bash and why I don't run fancy vim plugins.

I had a co-worker about 5 years ago who could do everything I did in tmux with screen. There really is no need to switch as long as your workflow is working for you.

I built a tmux session manager for myself, It uses a ruby configuration file similar to the one below, You can find it at https://github.com/minhajuddin/tummy . I feel ruby is more flexible at configuration than yaml.

    session "statictrain"
    directory "/home/minhajuddin/r/st/web"

    window "src", [
      pane("vim TODO"),
    ]

    window "server-iex", [
      pane("iex -S mix phoenix.server"),
      # the last argument is passed to tmux as raw arguments
      #pane("iex -S mix", :horizontal, "-l 8"),
      pane("git status; tail -f log/debug.log", :vertical),
    ]


    # if you comment this out it will focus the first window when the session is started
    #focus_window "server-iex"
    # focus_window 0 # you can even focus a window by index starting at 0

    # vim: filetype=ruby

I love tmux and use it locally as well as on remote servers. However I have not found a good way to nest remote sessions in a local session because of conflicting key bindings. Does anyone have an easy solution to this? My current solution is a separate terminal window for each remote session (connected via mosh user@host -- tmux attach). This is a minor annoyance.

My other problem is that when I restart my laptop I lose all local tmux sessions. It looks like this might be a solution via `tmuxp freeze`. Will this save bash history and stdout or only pane layouts?

I am also looking for a way to grep unified bash history across all hosts I use.

One idea I have to improve workflow / keep state across restarts is to vpn to a remote server and use my "main" terminal from there. When I need to run something locally I do it via mosh to local IP on vpn. This way local screen state is saved even across restarts (since server is up 24/7). However this is super convoluted and not ideal for many reasons.

I've been using tmux continuum for semi persistent sessions about 2 years now and been generally happy. There's good support for keeping stdout (pane contents) in between restarts and you can also keep a whitelist of applications allowed to be resumed throughout reboots.

https://github.com/tmux-plugins/tmux-continuum

As for nested sessions I usually bind ^B ^B to send-prefix which means it will call the nested session, if you keep this as a standard in all you tmux configs you'll always be able to nest by repeating ^B, and even if you haven't you can always do ^B :send-prefix

I've used tmux-continuum in conjunction with tmuxinator in order to easily keep sessions for different projects, however tmuxp should fill this purpose as well.

How often do you restart your laptop?

Restarting is a pain, having to restore tmux and emacs and chrome and whatnot, but since I restart about once per month it's still acceptable.

Well, I restart about once per month too. But that's not ideal. I would like to apply security updates as soon as they're available, but I always put it off because I know I'll have to restart and lose all session state.

I have the same problem and feel this is something we should not have so much trouble with in 2017. Any solutions?

Other than the configuration form, does this have uses cases that are different from a bash script(s) with tmux commands.

I do most of my work from within a single tmux session, so this isn't super useful for me. However, I heavily use tmuxifier [1] which I've extended with some custom shell scripts which further enhance my workflow.

Instead of launching tmux with a predefined session configuration, I launch a fresh session and then use tmuxifier to load window configurations as needed.

A large benefit of tmuxifier is that it's all written as a collection of shell scripts, so there are no additional dependencies. It also has really good tab completion.

1: https://github.com/jimeh/tmuxifier

I'm not a big user of tmux sessions, but i quite like all these tools pop up around tmux.

I am switching to Kakoune IDE, which doesn't have pane splitting/etc, it relies on a tool such as tmux to do splitting instead. So, needless to say Tmux has become even more crucial to my environment.

This is the kind of thing I really wish tmux had native support for, so I could use it on any system.

I find most systems don't have tmux installed by default anyway. But with the --user flag to pip, you can easily install tmuxp into your home directory.

agreed, I wonder if the author has tried to add support upstream?

Im pretty new to this and use tmuxinator from a recommendation by my dev team. Can someone explain to me the difference between this and tmuxinator?

The About Page lists the differences: http://tmuxp.git-pull.com/en/latest/about.html#differences-f...

Reply on news.ycombinator.com