I\'m currently using tmux with xterm-256color $TERM variable. When in bash under tmux, pressing home/end would insert tilde characters (~). Outside of tmux the home/end keys wor
If you want to stay with xterm-256color in tmux for some reason - use arch solution with inputrc. I tested it in tmux with rxvt, ruby irb, python, lua and home/end keys are ok. Probably every readline app will be ok.
From the arch wiki:
First things first:
do not set $TERM manually - let the terminal do it.
Many command line applications use the Readline library to read input. So properly configuring Readline can fix Home and End in many cases.
the default /etc/inputrc file does not include a mapping for home/end keys.
To check what the emitted escape sequence for these keys is:
1. Ctrl + V
2. Home
3. Spacebar
4. Ctrl + V
5. End
this will probably print: $ ^[[1~ ^[[4~
. So you have to add a mapping for these sequences to your inputrc (/etc/inputrc to be globally, or only for your user ~/.inputrc):
"\e[1~": beginning-of-line
"\e[4~": end-of-line
In tmux 2.0, you can just add these 2 lines in your .tmux.conf
:
bind -n End send-key C-e
bind -n Home send-key C-a
In my case it was a problem with zsh in tmux (bash in tmux was ok). None of the other anwsers here worked for me.
But adding this to .zshrc
fixed it:
bindkey "\E[1~" beginning-of-line
bindkey "\E[4~" end-of-line
Besides that I also have:
bindkey "\E[H" beginning-of-line
bindkey "\E[F" end-of-line
bindkey "\E[3~" delete-char
Add the following to your .tmux.conf
:
bind-key -n Home send Escape "OH"
bind-key -n End send Escape "OF"
And you're done!
After attempting each one of these, and several others I saw while perusing other answers and documentation, this finally worked for me in every scenario I threw at it. I can't promise the same for you, because everyone's scenarios are different, but this is what I ended up with.
This was discovered after introducing the same trial/error and logic from this somewhat related article. The only difference is where the translation is occurring; in my case, this happens within my .tmux.conf
, rather than .bashrc
or .zshrc
(Mainly because my home/end worked fine outside of tmux
)
You can debug this issue by using cat -v
like referenced in the article above.
Run cat -v
, then press the Home and End keys. Exit using Ctrl+C.
$ cat -v
Here's what my output looked like within tmux using zsh
, zsh
, and bash
:
tmux
➜ ~ cat -v
^[[1~^[[4~^C
zsh
➜ ~ cat -v
^[[H^[[F
bash
bash-3.2$ cat -v
^[[H^[[F
Compare the above examples to what we're expecting to see, by pairing tput
with cat -v
:
$ tput khome | cat -v; echo
^[OH
$ tput kend | cat -v; echo
^[OF
Because this problem exists solely with tmux
, and not within the emulators themselves, I opted to make the bind changes within the tmux configuration instead. By using bind-key
paired with send
, we can use the Escape
keyword paired with the sequence we want to achieve our translation. Thus:
bind-key -n NAME_OF_KEY send Escape SEQUENCE_GOES_HERE
This debugging and solutioning process can be applied to any other key translation issues. But, don't go too crazy. Some keys are mapped to certain escape sequences for a reason. Notice how bash
and zsh
received the ^[[H
sequence for Home instead of ^[OH
; it's probably not recommended we override this in our .zshrc
unless we're having major issues with this in zsh
.
I wasted a lot of time trying all off the above. In the end I reverted to barbarism:
sudo apt purge tmux
sudo apt install tmux
fixed it for me.
So I don't have enough points to comment,so I'll say it here instead. I believe the preferred solution is using
set -g default-terminal "screen-256color"
in your ~/.tmux.conf
. I actually had this problem a while ago and decided to go with sumanta's solution :
bind -n End send-key C-e
bind -n Home send-key C-a
However I had forgotten I left this in here and ended up having a similar issue with vim (home and end were copy pasting from registers) instead of zsh. In short bind DOES affect vim.