I have a ~/.tmux/dev
file which looks like this:
selectp -t 0 # select the first pane
splitw -h -p 50 # split it into two halves
selectp -t 1 # select the new, second (1) pane
splitw -v -p 50 # split it into two halves
selectp -t 0 # go back to the first pane
send-keys 'vim .' Enter
If I run tmux source-file ~/.tmux/dev
from inside a tmux session, it works fine.
I want to create a bash script that opens tmux and automatically runs those commands.
I tried running
tmux new 'tmux source-file ~/.tmux/dev'
but I only see two panes; the pane with vim is missing.
I have read How do I get tmux to open up a set of panes without manually entering them?, but before installing a tool for managing tmux configs, I would like to grok what's happening here.
Thanks in advance for any light you can shed on the subject.
Answer
This is what is happening:
tmux new 'tmux source-file ~/.tmux/dev'
The
new
commands creates a new session with a single window that has a single pane. The commandtmux source-file ~/.tmux/dev
runs in this new pane.- So, you have a new session
N
(where N is some number), with - a single window
N:0
(or whatever you havebase-index
set to), with - a single pane
N:0.0
(or whatever you havebase-pane-index
set to), - running the command
tmux source-file ~/.tmux/dev
.
- So, you have a new session
The
source-file
command is processed.- The extra panes are added.
- Pane 0 is (re)selected.
- The
send-keys
command then “types”vim .
+ Enter at pane 0.
This input is ignored because this pane is just running the tmux client that sent thesource-file
command.
- The tmux client exits, thus closing pane 0.
So the unexpected bit is that pane 0 (i.e. N:0.0
) is running (only) the source-file
command which ignores your “typed” command. This pane never runs an interactive shell that could interpret the “typed” command.
There are at least a couple of ways you can fix this:
Start
~/.tmux/dev
withnew-window
so that pane 0 is running your “default command” (i.e. probably an interactive shell).This method has the benefit of not assuming that your current pane is running an interactive shell, and also not assuming that the current pane is
0
(i.e. what happens if you run your original series of commands against a pane that is part of an already split window?). It means you can safely bindsource-file ~/.tmux/dev
to a key that you can run in any context (since it creates a new window for all of its panes). From the shell you can run eithertmux source-file ~/.tmux/dev
(to create a new window in the current session), or your originaltmux new 'tmux source-file ~/.tmux/dev'
to create a new session.A minor drawback to this method is that when you run
tmux new 'tmux source-file ~/.tmux/dev'
, the initial window will still run the client that sendssource-file
and exit fairly quickly. This means that your “main window” (the one with the splits) will be one higher than yourbase-index
and a future new window will be placed before the “main window”. You could fix this by using something like this:tmux new 'tmux move-window -t 99 \; source-file ~/.tmux/dev'
It moves the (ephemeral) initial window to a high index so that the
new-window
in~/.tmux/dev
will end up atbase-index
.Use (e.g.)
tmux new 'tmux source-file ~/.tmux/dev ; zsh -l'
so that the pane ends up running an interactive shell after thesource-file
command finishes.The ugly bit about this is that you end up “hard coding” your preferred shell into this command. Also, the
send-keys
input (vim .
+ Enter) is technically sent before the shell starts; this is probably okay, but may not always be completely reliable.You could avoid “hard coding” your shell by querying tmux for the
default-command
(or if that is not set,default-shell
(or if that is not set, using SHELL)), but that may be more work than you really want to do.
Comments
Post a Comment