Workflow in tmux(coderwall.com)
coderwall.com
Workflow in tmux
https://coderwall.com/p/_g2vpq
61 comments
The status bar with the arrow breadcrumbs is powerline: https://github.com/Lokaltog/powerline
There are bindings for tmux, bash, zsh, vim, and ipython (among others).
There are bindings for tmux, bash, zsh, vim, and ipython (among others).
The status bar with the arrow breadcrumbs _looks like_ powerline. If you read his tmux config, he's not actually using powerline, he just duplicated the appearance.
He is using the vim-powerline bundle for vim, but it looks like you're right about the tmux config.
tmux has its own powerline:
https://github.com/erikw/tmux-powerline
Actually that's been deprecated in favour of the one powerline to rule them all that "th" posted above.
I understand using console window managers when logged into a headless system where you don't otherwise have access to a UI, but I'm baffled by the desire to use console-based window managers within well defined GUI like OS X.
In OS X, there are multitudes of tools to allow you to manage windows. Spectacle is a simple one, Slate is extremely customizable.
Why not use the built-in OS X window manager to manager various windows rather than a console-based one? If you say the advantage is the shortcut keys, Slate lets you setup shortcut keys to do just about anything.
Can anyone give me a list of pros/cons for using a console-based window manager over a native one?
In OS X, there are multitudes of tools to allow you to manage windows. Spectacle is a simple one, Slate is extremely customizable.
Why not use the built-in OS X window manager to manager various windows rather than a console-based one? If you say the advantage is the shortcut keys, Slate lets you setup shortcut keys to do just about anything.
Can anyone give me a list of pros/cons for using a console-based window manager over a native one?
One use case I used to do often is switching between headless/remote and local use. Imagine sitting at your desktop, starting something, then detaching, going somewhere else... Then you ssh back to the desktop and resume the same session. Your stuff has been running there the whole time.
As the article concludes: "These tools are powerful not because you can use the keyboard instead of a mouse, they are powerful because you can combine them in new ways" (for context: through tmux-prefixed commands, your scripts can talk to your terminals). But more importantly, if you don't think of it as a replacement for a window manager it makes more sense - it's "only" a terminal multiplexer. You'll still have need/use for a great WM, too.
it is lightweight, contained, and excellent if you have a "unix-like" workflow. Typically I'll have a watch script, server, and vim in a given window, and it is super compact. Some cons are probably the learning curve required to see any advantage, and the fundamental lack of any respect for mousing, which can be in the pro column for many.
That's interesting. I practically never use the mouse to switch between windows in OS X or Windows.
The biggest problem I have with tmux is vertical splits don't work with native copy-paste because the selection goes across both panes. Using multiple terminal windows, on the other hand, doesn't have that issue.
The biggest problem I have with tmux is vertical splits don't work with native copy-paste because the selection goes across both panes. Using multiple terminal windows, on the other hand, doesn't have that issue.
Native copy/paste typically requires a mouse. using tmux's copy-mode and pasting doesn't require a mouse an still stays inside panes.
Using a mouse, you can use tmux's new (in 1.8) pane expansion. prefix + z causes the current pane to take up the entire window. prefix + z again and it goes back to normal. Essentially, it's a maximized/restore capability.
rad, learned a new trick. thanks!
But the tmux copy paste is horribly inefficient.
OT: Tmux/Screen are a little bit RSI inducing to me, to be used effectively. Any tips?
For tmux, I assign the bind-key to backtick (`) and last-window to TAB. Then do most of my work in window #1. On a US keyboard, I find it pretty easy to move between windows with `1, `2, `TAB, etc.
Remap caps lock to be a ctrl key, then preferably remap your prefix key to a. Caps+a is way easier to type.
This is also what I do.
I do ctrl+o because I hated having to hit ctr+a two times to go to the beginning of the line in console apps.
I would find Caps+a very difficult to type (since it uses the two weakest fingers). Have you ever tried Caps+d or Caps+f?
Ctrl+L is good because it's on the home row and typically used for uninteresting stuff anyway (like refreshing the terminal window).
My sequence to actually refresh the window is "Ctrl+L L"
My sequence to actually refresh the window is "Ctrl+L L"
Use the Alt key to navigate around: https://github.com/nviennot/tmux-config
It may just take a bit of work to make sure that the important tmux keybindings don't clash with those of the applications you will be running.
Remap your keys. Capslock makes for a very nice control key, cause really, that's the single most used modifier/power key that gets used aside from maybe shift. You can also remap the "lead-in" character.
I use ^j on both screen and tmux (tmux isn't on our prod servers). This frees up ^a in screen so ^a can send me to the beginning of a line, which is quite nice as I write a lot of long commands and it works in several different programs. It's just a really easy combo to hit that avoids chording or stretching your hands to do something like that constantly. My right hand does not hit the 'b' key for squat.
Honestly, a lot of stuff is configurable so that with some thought and planning (and knowledge and research) you can relieve a lot of weird movements with your hands.
I use ^j on both screen and tmux (tmux isn't on our prod servers). This frees up ^a in screen so ^a can send me to the beginning of a line, which is quite nice as I write a lot of long commands and it works in several different programs. It's just a really easy combo to hit that avoids chording or stretching your hands to do something like that constantly. My right hand does not hit the 'b' key for squat.
Honestly, a lot of stuff is configurable so that with some thought and planning (and knowledge and research) you can relieve a lot of weird movements with your hands.
I somewhat agree, and the suggestions from others are good, but something that also is a big help with RSI: take more breaks. I have a script set up to remind me to take a break every hour, and it dims my monitor for 10 minutes each time. That has made the largest difference for me.
The single most irritating thing about tmux is that viewers have to look at the same window or whatever it is called. My typical usage pattern is to connect twice, have one window where there is a long running task I want to monitor and a second where I am typing commands. But I can't show one in one connection and the other in the other connection.
Note that I use byobu to front end things, and when using screen this can easily be done. I have seen workarounds that involve using multiple copies of tmux talking to each other in various heroic configurations but that is silly.
Note that I use byobu to front end things, and when using screen this can easily be done. I have seen workarounds that involve using multiple copies of tmux talking to each other in various heroic configurations but that is silly.
I always have two copies of tmux running, for this very reason. Someone out there surely must have a better solution.
I used to do this all of the time in screen, but I haven't done so since switching to tmux (haven't run upon the situation). You've inspired me to look into it.
First, terminology. I know that tmux has: servers, clients, windows, sessions, and panes, but I've never bothered to understand how they fit together.
* server - The server is a process that listens on a unix socket, and accepts connections from clients. Each server manages one or more sessions, which is a grouping of windows.
* client - A terminal connected to the server. Each client connects to a single session on the server.
* session - A collection of windows on a server.
Each session has a single 'active window.' When you connect two clients to a single session, switching the current active window affects what both clients see.
Solution:
Windows can be shared between sessions, and a single window can be present in multiple sessions. This culminates in a tmux feature called "grouped sessions" where multiple sessions are linked and share the same windows. You can use this command:
First, terminology. I know that tmux has: servers, clients, windows, sessions, and panes, but I've never bothered to understand how they fit together.
* server - The server is a process that listens on a unix socket, and accepts connections from clients. Each server manages one or more sessions, which is a grouping of windows.
* client - A terminal connected to the server. Each client connects to a single session on the server.
* session - A collection of windows on a server.
Each session has a single 'active window.' When you connect two clients to a single session, switching the current active window affects what both clients see.
Solution:
Windows can be shared between sessions, and a single window can be present in multiple sessions. This culminates in a tmux feature called "grouped sessions" where multiple sessions are linked and share the same windows. You can use this command:
tmux new-session -t session-id
This is so much more complicated! When using byobu I use F3 and F4 to cycle to previous and next window. I can't understand why they think that by default I want all of the viewers to switch at once.
I think that the main issue that you're having is that 'active window' is an attribute of a session, and not of the client. If 'active window' were specific to a client, then two clients could switch windows independently while connected to the same session.
You could petition for an option to the `attach-session` command that automatically creates a new session grouped to the session that you're 'attaching' to. IIRC, you can't attach two 'clients' to the same (GNU) screen session unless you use the -x option, so it's not like it's the 'default' behaviour for screen either.
Edit:
I wasn't thinking, but `new-session` will automatically connect to the new session you created, so there is no need for an option to `attach-session`. So when you want to connect a second client, just:
You could petition for an option to the `attach-session` command that automatically creates a new session grouped to the session that you're 'attaching' to. IIRC, you can't attach two 'clients' to the same (GNU) screen session unless you use the -x option, so it's not like it's the 'default' behaviour for screen either.
Edit:
I wasn't thinking, but `new-session` will automatically connect to the new session you created, so there is no need for an option to `attach-session`. So when you want to connect a second client, just:
# find the session you want
$ tmux list-sessions
# create a grouped session
$ tmux new-session -t SESSION_ID
| This is so much more complicated!
| When using byobu I use F3 and F4 to cycle to
| previous and next window.
Since I use byobu I neither know nor care what is going on under the hood. I use 4 keystrokes - F2 to start a new shell, F3 to cycle back, F4 to cycle forwards and ctrl-F5 to reconnect sockets (GPG agent, DBUS etc).
I did switch it from screen to tmux because tmux definitely works better for other things and seems more responsive when there is lots of output. By default screen did let each client view independent of any other.
I don't see how to automate getting the behaviour I want (independent client views) as typing commands and feeding them into tmux would be a huge pain (especially as byobu is already doing that).
I did switch it from screen to tmux because tmux definitely works better for other things and seems more responsive when there is lots of output. By default screen did let each client view independent of any other.
I don't see how to automate getting the behaviour I want (independent client views) as typing commands and feeding them into tmux would be a huge pain (especially as byobu is already doing that).
It really depends on what your workflow is. If you only ever have a single tmux session, then you could write a quick script that starts a session if it doesn't exist, but if it does, automatically creates a mirrored session and connects to it. In this workflow, you can assume which session you want to group with, but if you work with multiple sessions, then there is no way to automatically do this. E.g., you could run something like:
Edit:
I've created a little script for this: https://github.com/bsandrow/tmux.sh
$ tmux.sh session-name
Edit:
I've created a little script for this: https://github.com/bsandrow/tmux.sh
I created a byobu ticket to cover this issue as it is what ultimately starts/connects tmux pointing to this thread. Thanks for the solution. https://bugs.launchpad.net/byobu/+bug/1168734
Having the viewers switch by default is useful for demos, when you are showing something to someone. And it's the simplest behaviour for their data structure. So I can see some logic to why they designed it that way.
I'm glad you raised this issue because I've only recently moved to tmux and would have been stung by it.
Could you abstract it away behind a shell alias? I used this:
I'm glad you raised this issue because I've only recently moved to tmux and would have been stung by it.
Could you abstract it away behind a shell alias? I used this:
alias tmuxc='tmux new-session -t 0'I don't know since I am using byobu to front end all this, and it is what runs tmux/screen under the hood in the end.
I believe tmux 1.8 supports this use case.
From the manpage (for new-session): If -t is given, the new session is grouped with target-session. This means they share the same set of windows - all windows from target-session are linked to the new session and any subsequent new windows or windows being closed are applied to both sessions. The current and previous window and any session options remain independent and either session may be killed without affecting the other.
From the manpage (for new-session): If -t is given, the new session is grouped with target-session. This means they share the same set of windows - all windows from target-session are linked to the new session and any subsequent new windows or windows being closed are applied to both sessions. The current and previous window and any session options remain independent and either session may be killed without affecting the other.
I've started running tmux in all my terminals automatically, and conveniently sharing a "master" session between them all.
Instead of running tmux directly, I have a small script which creates a session named TMUX-MASTER if it doesn't already exist, and immediately detaches it. All the clients that I actually interact with are created separately and automatically grouped with the TMUX-MASTER session.
To prevent my system from being clogged by dozens of detached client sessions, I rebound prefix+d to kill-session, killing the client session but leaving my TMUX-MASTER session untouched. Closing terminals while running these client sessions, however, still leaves my system cluttered with dormant client sessions.
I'd like to see if a "ephemeral" option (it'd need a better name) could easily be added to new-session, which would cause the created session to just die when it's told to detach, or receives the HUP signal. It'd simplify things a bit.
Instead of running tmux directly, I have a small script which creates a session named TMUX-MASTER if it doesn't already exist, and immediately detaches it. All the clients that I actually interact with are created separately and automatically grouped with the TMUX-MASTER session.
To prevent my system from being clogged by dozens of detached client sessions, I rebound prefix+d to kill-session, killing the client session but leaving my TMUX-MASTER session untouched. Closing terminals while running these client sessions, however, still leaves my system cluttered with dormant client sessions.
I'd like to see if a "ephemeral" option (it'd need a better name) could easily be added to new-session, which would cause the created session to just die when it's told to detach, or receives the HUP signal. It'd simplify things a bit.
I started using tmux.. then switched to stumpwm which is too awesome to explain here. Embrace the full power of emacs and your Window Manager.
stumpwm is a window manager. tmux is a terminal multiplexer. They are not the same thing and using one does not preclude using the other.
*Started using tmux, then realized for my needs stumpwm was better. Obviously these are two different beasts. I still often use tmux on remote server for instance. However, if you use tmux locally, then a tiling manager might be better.
Exactly. I've been using xmonad for years now and I've tried to start using tmux for several occasions. I've never found any advantage of it compared to my different xmonad layouts: tabbed, tall, tall mirrored and grid.
Why not both? If you use tmux for your terminals you get persistence in case you need to restart X, or when you log in remotely.
Is there a way (short of writing a script) that will allow me to shuffle windows left and right, and/or move a window and slide the rest down?
Imagine having windows A, B, C, and D respectively in positions 0, 1, 2, and 3. I'd like to move D into position 1 so they end up in this order: A, D, B, C.
Haven't figured out how to pull this off yet.
Imagine having windows A, B, C, and D respectively in positions 0, 1, 2, and 3. I'd like to move D into position 1 so they end up in this order: A, D, B, C.
Haven't figured out how to pull this off yet.
I do it like this:
It seems to be what you want.
bind-key ) swap-window -t +
bind-key ( swap-window -t -
It seems to be what you want.
That works beautifully! Thank you.
To get copy/paste to play nice in OSX you have to go through some Herculean tasks. I made it work with netcat yesterday. I was running an http server to do it :)
https://github.com/base698/tmux-copy-paste-mac-osx
https://github.com/base698/tmux-copy-paste-mac-osx
This is basically what I was doing except with redis instead of netcat. I was happy to see copy-pipe in v1.8.
bind C-y run-shell "reattach-to-user-namespace -l zsh -c 'tmux saveb - | pbcopy'"
works for me.
works for me.
What's wrong with using reattach-to-user-namespace?
It involves compiling native code and its easier to do with a shell script?
I know what you mean. I translated that to a python script a while ago for myself so I could stick it on other boxes without having to compile it. It's now a gist – https://gist.github.com/chirayuk/5377283
I'd much rather run the native code, if my other option is firing up an interpreter. Shrug.
If others are looking for a great config to start out with definitely check out Brian P. Hogan's tmux: Productive Mouse-Free Development [1]. It is a great quick intro to tmux that demos and steps through the creation of a great tmux.conf
[1] http://pragprog.com/book/bhtmux/tmux