Every time I reopen tmux, some of the settings in my .tmux.conf are reset, and I have to run tmux source-file ~/.tmux.conf to reapply them. Oddly, some settings are not reset.
For example, these survive across tmux sessions:
# Use | and - for splitting windows
bind-key | split-window -h
bind-key - split-window -v
These reset every session:
# Change default 'prefix' key to '`'
set prefix `
unbind-key C-b
bind-key ` send-prefix
Why the difference in behavior?
And is there a way to automatically reload .tmux.conf whenever a tmux session starts?
set -g prefix `
Stops those commands from resetting.
Automatically reloading them is unnecessary if they don't reset, and the ones that reset here are the set-prefix (or "set-option") block because set-option is sensitive to "session mode". Without -g, set-option defaults to session mode. But since there's initially no tmux session to apply itself to, it doesn't work until .tmux.conf is re-sourced while in a new tmux session. From the man page,
If -g is given, the global session or window option is set.
Setting it instead to the global session pre-applies the command to all new tmux sessions.
Related
trying to setup a staging server for an API which I'm building using Django - and so far I was cutting corners, starting the thing using python manage.py runserver. But now that the setup grew a bit more complex, I decided to build an ansible playbok. Everything worked fine until I got to launching gunicorn - because I want it to run inside a tmux session. Manual process doesn't seem to trivially translate to ansible. I've been manually creating tmux session:
tmux new-session -A -s api
and then running gunicorn inside this new "environment" (subshell?)
The thing is (as is probably obvious to ansible veterans), when I get to running the first step, my playbook just hangs, and never gets to the next step, which is where gunicorn is to be started. I suppose this is because I'm starting a new shell with tmux, and ansible is lost, not hearing back (because, my guess, it's still waiting for a response on the original shell? which will never come). Is there a right way to execute the "tmux" step, letting ansible use it as a context/environment for the next step, or should I just be content with ansible doing the setup, and do the tmux thing manually? I had a similar problem, when dealing with the fact that gunicorn is inside a virtualenv, but the workaround is to use a full path, which includes the virtualenv guts. Not sure if there's a similar workaround with tmux...
thanks y'all
tmux immediately attaches to the new session, and doesn't exit until you detach from the session or the last process in the session ends. Until tmux exits, the rest of your script hangs.
You can use the -D option to prevent attaching to the session, whether or not it needs to be created.
tmux new-session -AD -s api
The rest of your script can now proceed.
tmux new-session -AD -s api is a shortcut for
tmux has-session -t api || tmux new-session -d -s api
I want to have more control over a time consuming cron job running on a server. That is, be able to see progress, stop running code if necessary and etc..
I thought that this would be possible using a tmux session, but I can not figure out how.
I know that you can start new tmux sessions and run code inside it like this:
tmux new-session -d -s session_name "some code"
I've tried the obvious solution like this:
tmux new-session -s session_name
**exit session**
tmux a -t session_name "some code"
Is this even possible? Any advice is appreciated.
You could send the key to the tmux session:
tmux send -t session_name ls ENTER
if you need to send to a specific panel:
tmux send -t session_name.(panelnumber) ls ENTER
example:
tmux send -t session_name.0 ls ENTER
I'm using the tmux-continuum and tmux-resurrect plugins. If I kill tmux (restarting my machine for example) and then run the following commands:
$ tmux ls
$ failed to connect to server: No such file or directory
Then when I start tmux it automatically restores my saved sessions plus an unnamed session (usually 0)
$ tmux
$ tmux ls
0: 1 windows (created...)
saved_session_1: 1 windows (created...)
saved_session_2: 1 windows (created...)
...
My current workflow goes like this:
Start tmux
Detach from tmux
Attach to the unnamed session
Kill unnamed session
Attach to one of my saved sessions
I don't want to have to repeat this every time I restart tmux. How can I restore my saved tmux sessions without creating the unnamed session?
If I understand correctly your question this is a common issue with tmux-resurrect. The solution given here (currently the last comment in the Github discussion) has worked for me.
Add the following to your .tmux.conf and then do source ~.tmux.conf(if that is the path of your conf file):
set -g #resurrect-hook-pre-restore-pane-processes 'tmux switch-client -n && tmux kill-session -t=0'
This a hook for tmux-resurrect which tells it to kill session 0 before restoring the panels.
Note: since the name of the session (-t=0) is hardcoded it will work only for that session, hence only if you do restore when you start the tmux server the first time, if you restore from sessions after 0 nothing will happen (which is nice to avoid kill sessions accidentally).
Run the following command (preferably make an alias it):
$ tmux new-session -A -s [session-name]
Flag meaning:
-s refers to session name.
-A In case session-name exists, command will act like attach-session instead of new-session.
Refer to the man page for official documentation:
$ man tmux
new-session [-AdDEP] [-c start-directory] [-F format] [-n window-name] [-s session-name] [-t
target-session] [-x width] [-y height] [shell-command]
(alias: new)
Create a new session with name session-name.
The new session is attached to the current terminal unless -d is given. window-name and
shell-command are the name of and shell command to execute in the initial window. If -d
is used, -x and -y specify the size of the initial window (80 by 24 if not given).
If run from a terminal, any termios(4) special characters are saved and used for new win‐
dows in the new session.
The -A flag makes new-session behave like attach-session if session-name already exists;
in this case, -D behaves like -d to attach-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,
any new windows are linked to both sessions and any windows closed removed from both ses‐
sions. The current and previous window and any session options remain independent and
either session may be killed without affecting the other. -n and shell-command are
invalid if -t is used.
The -P option prints information about the new session after it has been created. By
default, it uses the format ‘#{session_name}:’ but a different format may be specified
with -F.
If -E is used, the update-environment option will not be applied.
You could simply launch tmux by tmux a (i.e. attach to "existing" sessions). This would trigger tmux-continuum to first restore all sessions and then you'll get attached to one of them.
Works fine for me. I'm running tmux 3.0a with tmux-resurrect and tmux-continuum plugins.
I have been trying to figure this one out for two weeks with no luck.
I am using Iterm2 on OSX, with tmux as the session manager. I have VIM setup with the following two bindings in the .vimrc
"_____Easy change tab left and right____
nnoremap <C-Left> :tabprevious<CR>
nnoremap <C-Right> :tabnext<CR>
nnoremap <C-h> :tabprevious<CR>
nnoremap <C-l> :tabnext<CR>
Now the strange part is that the ctrl h and l shortcuts work perfectly while the left arrow says.
E349: No identifier under cursor
Which seems unrelated to what should be happening (It works perfectly outside of TMUX!), but checking my mappings using :map does not show any conflicting mappings. But I just cannot figure this out. Any help at all would be greatly appreciated. Below is my tux.conf file. Since this works perfectly outside of tmux I don't believe the vimrc should have anything to do with this.
I have a feeling that its Iterm2 thats sending strange things to the terminal and tmux is misinterpreting them, but I have no idea how to fix it.
tmux.conf
#set -g default-terminal "xterm-256color"
set -sg escape-time 0
# remap prefix from 'C-b' to 'C-a'
unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix
# split panes using | and -
bind | split-window -h
bind - split-window -v
unbind '"'
unbind %
# reload config file (change file location to your the tmux.conf you want to use)
bind r source-file ~/.tmux.conf
# switch panes using Alt-arrow without prefix
bind -n M-Left select-pane -L
bind -n M-Right select-pane -R
bind -n M-Up select-pane -U
bind -n M-Down select-pane -D
# Enable mouse mode (tmux 2.1 and above)
set -g mouse on
# don't rename windows automatically
set-option -g allow-rename off
# Use Alt-arrow keys without prefix key to switch panes
bind -n M-S-Left previous-window
bind -n M-S-Right next-window
# Dont clear screen after other program is on
set-window-option -g alternate-screen on
#set-window-option -g xterm-keys on
If you uncommented these lines:
#set -g default-terminal "xterm-256color"
#set-window-option -g xterm-keys on
then tmux would
set the TERM environment variable to a terminal description which defines these keys, and
send the xterm-style control arrow-keys that vim expects.
Without those two changes, TERM is set to screen (which doesn't define the keys), and tmux will send different sequences for the control arrow-keys (which happen to not be in either terminal description).
A related problem is that you cannot resize panes using meta-arrow key in tmux from the OSX Terminal. The solution is to select the "Use Option as Meta key" and delete the rows in the Keyboard section corresponding to option-arrow.
How do I increase the scrollback buffer size in tmux?
If I enter copy mode, the number of available scrollback lines is always below 2000.
The history limit is a pane attribute that is fixed at the time of pane creation and cannot be changed for existing panes. The value is taken from the history-limit session option (the default value is 2000).
To create a pane with a different value you will need to set the appropriate history-limit option before creating the pane.
To establish a different default, you can put a line like the following in your .tmux.conf file:
set-option -g history-limit 3000
Note: Be careful setting a very large default value, it can easily consume lots of RAM if you create many panes.
For a new pane (or the initial pane in a new window) in an existing session, you can set that session’s history-limit. You might use a command like this (from a shell):
tmux set-option history-limit 5000 \; new-window
For (the initial pane of the initial window in) a new session you will need to set the “global” history-limit before creating the session:
tmux set-option -g history-limit 5000 \; new-session
Note: If you do not re-set the history-limit value, then the new value will be also used for other panes/windows/sessions created in the future; there is currently no direct way to create a single new pane/window/session with its own specific limit without (at least temporarily) changing history-limit (though show-option (especially in 1.7 and later) can help with retrieving the current value so that you restore it later).
Open tmux configuration file with the following command:
vim ~/.tmux.conf
In the configuration file add the following line:
set -g history-limit 5000
Log out and log in again, start a new tmux windows and your limit is 5000 now.
This builds on ntc2 and Chris Johnsen's answer. I am using this whenever I want to create a new session with a custom history-limit. I wanted a way to create sessions with limited scrollback without permanently changing my history-limit for future sessions.
tmux set-option -g history-limit 100 \; new-session -s mysessionname \; set-option -g history-limit 2000
This works whether or not there are existing sessions. After setting history-limit for the new session it resets it back to the default which for me is 2000.
I created an executable bash script that makes this a little more useful. The 1st parameter passed to the script sets the history-limit for the new session and the 2nd parameter sets its session name:
#!/bin/bash
tmux set-option -g history-limit "${1}" \; new-session -s "${2}" \; set-option -g history-limit 2000
This will fix it in one liner:
echo "set -g history-limit 5000" >> ~/.tmux.conf
For those of you that don't know where to find .tmux.conf file, you can simply create a new file at ~/.tmux.conf, then add this single line into the file set-option -g history-limit 50000 if above command will throw error. (comment taken from #C.Lee on this answer)