Using putty, Left and Right keys move cursor one word, instead of one char
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have looked for a solution to this OhMyZSH!
problem for a few days now, but can't find a solution.
Admittedly, I do not understand how zle
really works, same for bindkey
. Same goes for the way terminal emulators send "control sequences", and what the "terminal type" means (xterm
, versus xterm-256-color
, and others). Same for the "Application mode"
The setup
I have 2 machines where the latest version of OhMyZSH is installed, commit c3b072
:
- machine A: SLES 11 SP4, running
zsh 4.3.6 (x86_64-suse-linux-gnu)
- machine B: Ubuntu 16.04, running
zsh 5.1.1 (x86_64-ubuntu-linux-gnu)
I connect to either machine using Putty running on Windows, with terminal type xterm
, and in UTF-8 translation mode.
My zshrc
files are pretty much vanilla OhMyZSH
templates, I have just changed the prompt to dieter
on machine A, and powerlevel-9k
[https://github.com/bhilburn/powerlevel9k] on machine B.
What I observe on machine A (aka the "bad" one)
When I edit my command line, the Left and Right cursor keys move one whole word (instead of 1 single character).
Home and End keys though, bring the cursor to the beginning and end of the line, as expected.
This described behaviour applies when in emacs
mode (bindkey -e
).
When I go to vim
mode (bindkey -v
), the Left and Right arrows move 1 character, but the Home and End keys don't move the cursor to the beginning and end of the line. Instead, they switch the case of the character under the cursor.
What I observe on machine B (aka the "good" one)
Left and Right keys move the cursor one single char. Home and end keys move the cursor to the beginning and end of line resp. Ctrl+A and Ctrl+E combos bring my cursor to the beginning and end resp.
This is the behaviour I would like for all my shells.
What I have found so far
I think it is a bindkey
issue. But I know next to nothing about that, and I've had a hard time finding any doc on this zsh
built-in.
Running zsh -v
on both machines at login time gives very different results, despite similar .zshrc
files.
Could someone explain to me what is causing these 2 machines to behave so differently, and how I can change my configuration so that consistency is regained, and all my shells behave like on machine B (aka the "good" one)?
I'm sure you will let me know if you need more information that I don't know is needed.
Many thanks
zsh oh-my-zsh zle
add a comment |Â
up vote
1
down vote
favorite
I have looked for a solution to this OhMyZSH!
problem for a few days now, but can't find a solution.
Admittedly, I do not understand how zle
really works, same for bindkey
. Same goes for the way terminal emulators send "control sequences", and what the "terminal type" means (xterm
, versus xterm-256-color
, and others). Same for the "Application mode"
The setup
I have 2 machines where the latest version of OhMyZSH is installed, commit c3b072
:
- machine A: SLES 11 SP4, running
zsh 4.3.6 (x86_64-suse-linux-gnu)
- machine B: Ubuntu 16.04, running
zsh 5.1.1 (x86_64-ubuntu-linux-gnu)
I connect to either machine using Putty running on Windows, with terminal type xterm
, and in UTF-8 translation mode.
My zshrc
files are pretty much vanilla OhMyZSH
templates, I have just changed the prompt to dieter
on machine A, and powerlevel-9k
[https://github.com/bhilburn/powerlevel9k] on machine B.
What I observe on machine A (aka the "bad" one)
When I edit my command line, the Left and Right cursor keys move one whole word (instead of 1 single character).
Home and End keys though, bring the cursor to the beginning and end of the line, as expected.
This described behaviour applies when in emacs
mode (bindkey -e
).
When I go to vim
mode (bindkey -v
), the Left and Right arrows move 1 character, but the Home and End keys don't move the cursor to the beginning and end of the line. Instead, they switch the case of the character under the cursor.
What I observe on machine B (aka the "good" one)
Left and Right keys move the cursor one single char. Home and end keys move the cursor to the beginning and end of line resp. Ctrl+A and Ctrl+E combos bring my cursor to the beginning and end resp.
This is the behaviour I would like for all my shells.
What I have found so far
I think it is a bindkey
issue. But I know next to nothing about that, and I've had a hard time finding any doc on this zsh
built-in.
Running zsh -v
on both machines at login time gives very different results, despite similar .zshrc
files.
Could someone explain to me what is causing these 2 machines to behave so differently, and how I can change my configuration so that consistency is regained, and all my shells behave like on machine B (aka the "good" one)?
I'm sure you will let me know if you need more information that I don't know is needed.
Many thanks
zsh oh-my-zsh zle
You might want to include the output of yourzsh -v
in your question.
â EightBitTony
Jan 23 at 13:51
zsh -v
traces have been added to this gist: gist.github.com/guneemwelloeux/34ee3943ac32847895dc4c57f74c5ff7. Careful though, the files are 6k lines long each, so the page is pretty heavy to load.
â Gunee
Jan 24 at 10:40
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have looked for a solution to this OhMyZSH!
problem for a few days now, but can't find a solution.
Admittedly, I do not understand how zle
really works, same for bindkey
. Same goes for the way terminal emulators send "control sequences", and what the "terminal type" means (xterm
, versus xterm-256-color
, and others). Same for the "Application mode"
The setup
I have 2 machines where the latest version of OhMyZSH is installed, commit c3b072
:
- machine A: SLES 11 SP4, running
zsh 4.3.6 (x86_64-suse-linux-gnu)
- machine B: Ubuntu 16.04, running
zsh 5.1.1 (x86_64-ubuntu-linux-gnu)
I connect to either machine using Putty running on Windows, with terminal type xterm
, and in UTF-8 translation mode.
My zshrc
files are pretty much vanilla OhMyZSH
templates, I have just changed the prompt to dieter
on machine A, and powerlevel-9k
[https://github.com/bhilburn/powerlevel9k] on machine B.
What I observe on machine A (aka the "bad" one)
When I edit my command line, the Left and Right cursor keys move one whole word (instead of 1 single character).
Home and End keys though, bring the cursor to the beginning and end of the line, as expected.
This described behaviour applies when in emacs
mode (bindkey -e
).
When I go to vim
mode (bindkey -v
), the Left and Right arrows move 1 character, but the Home and End keys don't move the cursor to the beginning and end of the line. Instead, they switch the case of the character under the cursor.
What I observe on machine B (aka the "good" one)
Left and Right keys move the cursor one single char. Home and end keys move the cursor to the beginning and end of line resp. Ctrl+A and Ctrl+E combos bring my cursor to the beginning and end resp.
This is the behaviour I would like for all my shells.
What I have found so far
I think it is a bindkey
issue. But I know next to nothing about that, and I've had a hard time finding any doc on this zsh
built-in.
Running zsh -v
on both machines at login time gives very different results, despite similar .zshrc
files.
Could someone explain to me what is causing these 2 machines to behave so differently, and how I can change my configuration so that consistency is regained, and all my shells behave like on machine B (aka the "good" one)?
I'm sure you will let me know if you need more information that I don't know is needed.
Many thanks
zsh oh-my-zsh zle
I have looked for a solution to this OhMyZSH!
problem for a few days now, but can't find a solution.
Admittedly, I do not understand how zle
really works, same for bindkey
. Same goes for the way terminal emulators send "control sequences", and what the "terminal type" means (xterm
, versus xterm-256-color
, and others). Same for the "Application mode"
The setup
I have 2 machines where the latest version of OhMyZSH is installed, commit c3b072
:
- machine A: SLES 11 SP4, running
zsh 4.3.6 (x86_64-suse-linux-gnu)
- machine B: Ubuntu 16.04, running
zsh 5.1.1 (x86_64-ubuntu-linux-gnu)
I connect to either machine using Putty running on Windows, with terminal type xterm
, and in UTF-8 translation mode.
My zshrc
files are pretty much vanilla OhMyZSH
templates, I have just changed the prompt to dieter
on machine A, and powerlevel-9k
[https://github.com/bhilburn/powerlevel9k] on machine B.
What I observe on machine A (aka the "bad" one)
When I edit my command line, the Left and Right cursor keys move one whole word (instead of 1 single character).
Home and End keys though, bring the cursor to the beginning and end of the line, as expected.
This described behaviour applies when in emacs
mode (bindkey -e
).
When I go to vim
mode (bindkey -v
), the Left and Right arrows move 1 character, but the Home and End keys don't move the cursor to the beginning and end of the line. Instead, they switch the case of the character under the cursor.
What I observe on machine B (aka the "good" one)
Left and Right keys move the cursor one single char. Home and end keys move the cursor to the beginning and end of line resp. Ctrl+A and Ctrl+E combos bring my cursor to the beginning and end resp.
This is the behaviour I would like for all my shells.
What I have found so far
I think it is a bindkey
issue. But I know next to nothing about that, and I've had a hard time finding any doc on this zsh
built-in.
Running zsh -v
on both machines at login time gives very different results, despite similar .zshrc
files.
Could someone explain to me what is causing these 2 machines to behave so differently, and how I can change my configuration so that consistency is regained, and all my shells behave like on machine B (aka the "good" one)?
I'm sure you will let me know if you need more information that I don't know is needed.
Many thanks
zsh oh-my-zsh zle
edited Jan 24 at 9:56
asked Jan 23 at 12:58
Gunee
1086
1086
You might want to include the output of yourzsh -v
in your question.
â EightBitTony
Jan 23 at 13:51
zsh -v
traces have been added to this gist: gist.github.com/guneemwelloeux/34ee3943ac32847895dc4c57f74c5ff7. Careful though, the files are 6k lines long each, so the page is pretty heavy to load.
â Gunee
Jan 24 at 10:40
add a comment |Â
You might want to include the output of yourzsh -v
in your question.
â EightBitTony
Jan 23 at 13:51
zsh -v
traces have been added to this gist: gist.github.com/guneemwelloeux/34ee3943ac32847895dc4c57f74c5ff7. Careful though, the files are 6k lines long each, so the page is pretty heavy to load.
â Gunee
Jan 24 at 10:40
You might want to include the output of your
zsh -v
in your question.â EightBitTony
Jan 23 at 13:51
You might want to include the output of your
zsh -v
in your question.â EightBitTony
Jan 23 at 13:51
zsh -v
traces have been added to this gist: gist.github.com/guneemwelloeux/34ee3943ac32847895dc4c57f74c5ff7. Careful though, the files are 6k lines long each, so the page is pretty heavy to load.â Gunee
Jan 24 at 10:40
zsh -v
traces have been added to this gist: gist.github.com/guneemwelloeux/34ee3943ac32847895dc4c57f74c5ff7. Careful though, the files are 6k lines long each, so the page is pretty heavy to load.â Gunee
Jan 24 at 10:40
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
You must configure your terminal type as putty
, putty-256color
, or putty-sco
when using PuTTY. They are the only terminal types whose entries in the terminfo database correctly describe PuTTY.
It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm
and xterm-256color
entries in the terminfo database correctly describe them.
This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm
and xterm-256color
entries do not even describe all versions of XTerm, let alone other terminal emulators.
PuTTY's doco such as the page hyperlinked there by M. Dickey, even today 16 years since the putty
entry was added to terminfo, unfortunately promotes this mis-use of the xterm
terminal type, but a mis-use it is, and this is the very sort of application misbehaviour that occurs.
Comparing the terminfo database entries for xterm-256color
and putty-256color
reveals what is happening with your â±Â Home and â²Â End keys:
% infocmp xterm-256color putty-256color|grep -F kend
kend: 'EOF', 'E[4~'.
% infocmp xterm-256color putty-256color|grep -F khome
khome: 'EOH', 'E[1~'.
%
As you can see, an application that is told that it is dealing with XTerm expects to receive (from the terminal) the control sequence âOH
for the â±Â Home key and the control sequence âOF
for the â²Â End key. But PuTTY actually sends the control sequences â[1~
and â[4~
(respectively) instead.
Your application, the Z shell, expecting the the XTerm keyboard control sequences (because you have erroneously told it that your terminal has the type xterm
), does not recognize the PuTTY control sequences, and in fact breaks them down into the vi
-mode commands to exit insert mode (â
) and swap the case of the current character (~
).
Further reading
- Where does the TERM environment variable default get set?
- Fish shell shows dark-grey "âà ½" characters in prompt
- https://unix.stackexchange.com/a/444270/5132
Thank you for the very useful information. After settingTERM
toputty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I starttmux
, the Home+arrow combos move by one word again...
â Gunee
Jan 24 at 9:48
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changingTERM
, you might get more consistent behavior by runningreset
.
â Thomas Dickey
Jan 24 at 10:22
Out of tmux,reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.
â Gunee
Jan 24 at 10:31
add a comment |Â
up vote
0
down vote
As kindly pointed by JdeBP, my TERM
was wrongly set.
I was finally able to have everything working consistently with the following steps:
- Set terminal type in Putty to
putty
- Deactivate application mode for cursor and keypad in Putty
- Add the following lines to my
.tmux.conf
fileset -g default-terminal "$TERM"
to prevent tmux from usingscreen
by defaultset -g terminal-overrides "putty*:kLFT5=eOD:kRIT5=eOC:kUP5=eOA:kDN5=eOB:smkx@:rmkx@"
to have the Left and Right keys move by one char, instead of one word
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
You must configure your terminal type as putty
, putty-256color
, or putty-sco
when using PuTTY. They are the only terminal types whose entries in the terminfo database correctly describe PuTTY.
It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm
and xterm-256color
entries in the terminfo database correctly describe them.
This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm
and xterm-256color
entries do not even describe all versions of XTerm, let alone other terminal emulators.
PuTTY's doco such as the page hyperlinked there by M. Dickey, even today 16 years since the putty
entry was added to terminfo, unfortunately promotes this mis-use of the xterm
terminal type, but a mis-use it is, and this is the very sort of application misbehaviour that occurs.
Comparing the terminfo database entries for xterm-256color
and putty-256color
reveals what is happening with your â±Â Home and â²Â End keys:
% infocmp xterm-256color putty-256color|grep -F kend
kend: 'EOF', 'E[4~'.
% infocmp xterm-256color putty-256color|grep -F khome
khome: 'EOH', 'E[1~'.
%
As you can see, an application that is told that it is dealing with XTerm expects to receive (from the terminal) the control sequence âOH
for the â±Â Home key and the control sequence âOF
for the â²Â End key. But PuTTY actually sends the control sequences â[1~
and â[4~
(respectively) instead.
Your application, the Z shell, expecting the the XTerm keyboard control sequences (because you have erroneously told it that your terminal has the type xterm
), does not recognize the PuTTY control sequences, and in fact breaks them down into the vi
-mode commands to exit insert mode (â
) and swap the case of the current character (~
).
Further reading
- Where does the TERM environment variable default get set?
- Fish shell shows dark-grey "âà ½" characters in prompt
- https://unix.stackexchange.com/a/444270/5132
Thank you for the very useful information. After settingTERM
toputty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I starttmux
, the Home+arrow combos move by one word again...
â Gunee
Jan 24 at 9:48
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changingTERM
, you might get more consistent behavior by runningreset
.
â Thomas Dickey
Jan 24 at 10:22
Out of tmux,reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.
â Gunee
Jan 24 at 10:31
add a comment |Â
up vote
1
down vote
accepted
You must configure your terminal type as putty
, putty-256color
, or putty-sco
when using PuTTY. They are the only terminal types whose entries in the terminfo database correctly describe PuTTY.
It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm
and xterm-256color
entries in the terminfo database correctly describe them.
This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm
and xterm-256color
entries do not even describe all versions of XTerm, let alone other terminal emulators.
PuTTY's doco such as the page hyperlinked there by M. Dickey, even today 16 years since the putty
entry was added to terminfo, unfortunately promotes this mis-use of the xterm
terminal type, but a mis-use it is, and this is the very sort of application misbehaviour that occurs.
Comparing the terminfo database entries for xterm-256color
and putty-256color
reveals what is happening with your â±Â Home and â²Â End keys:
% infocmp xterm-256color putty-256color|grep -F kend
kend: 'EOF', 'E[4~'.
% infocmp xterm-256color putty-256color|grep -F khome
khome: 'EOH', 'E[1~'.
%
As you can see, an application that is told that it is dealing with XTerm expects to receive (from the terminal) the control sequence âOH
for the â±Â Home key and the control sequence âOF
for the â²Â End key. But PuTTY actually sends the control sequences â[1~
and â[4~
(respectively) instead.
Your application, the Z shell, expecting the the XTerm keyboard control sequences (because you have erroneously told it that your terminal has the type xterm
), does not recognize the PuTTY control sequences, and in fact breaks them down into the vi
-mode commands to exit insert mode (â
) and swap the case of the current character (~
).
Further reading
- Where does the TERM environment variable default get set?
- Fish shell shows dark-grey "âà ½" characters in prompt
- https://unix.stackexchange.com/a/444270/5132
Thank you for the very useful information. After settingTERM
toputty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I starttmux
, the Home+arrow combos move by one word again...
â Gunee
Jan 24 at 9:48
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changingTERM
, you might get more consistent behavior by runningreset
.
â Thomas Dickey
Jan 24 at 10:22
Out of tmux,reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.
â Gunee
Jan 24 at 10:31
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
You must configure your terminal type as putty
, putty-256color
, or putty-sco
when using PuTTY. They are the only terminal types whose entries in the terminfo database correctly describe PuTTY.
It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm
and xterm-256color
entries in the terminfo database correctly describe them.
This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm
and xterm-256color
entries do not even describe all versions of XTerm, let alone other terminal emulators.
PuTTY's doco such as the page hyperlinked there by M. Dickey, even today 16 years since the putty
entry was added to terminfo, unfortunately promotes this mis-use of the xterm
terminal type, but a mis-use it is, and this is the very sort of application misbehaviour that occurs.
Comparing the terminfo database entries for xterm-256color
and putty-256color
reveals what is happening with your â±Â Home and â²Â End keys:
% infocmp xterm-256color putty-256color|grep -F kend
kend: 'EOF', 'E[4~'.
% infocmp xterm-256color putty-256color|grep -F khome
khome: 'EOH', 'E[1~'.
%
As you can see, an application that is told that it is dealing with XTerm expects to receive (from the terminal) the control sequence âOH
for the â±Â Home key and the control sequence âOF
for the â²Â End key. But PuTTY actually sends the control sequences â[1~
and â[4~
(respectively) instead.
Your application, the Z shell, expecting the the XTerm keyboard control sequences (because you have erroneously told it that your terminal has the type xterm
), does not recognize the PuTTY control sequences, and in fact breaks them down into the vi
-mode commands to exit insert mode (â
) and swap the case of the current character (~
).
Further reading
- Where does the TERM environment variable default get set?
- Fish shell shows dark-grey "âà ½" characters in prompt
- https://unix.stackexchange.com/a/444270/5132
You must configure your terminal type as putty
, putty-256color
, or putty-sco
when using PuTTY. They are the only terminal types whose entries in the terminfo database correctly describe PuTTY.
It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm
and xterm-256color
entries in the terminfo database correctly describe them.
This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm
and xterm-256color
entries do not even describe all versions of XTerm, let alone other terminal emulators.
PuTTY's doco such as the page hyperlinked there by M. Dickey, even today 16 years since the putty
entry was added to terminfo, unfortunately promotes this mis-use of the xterm
terminal type, but a mis-use it is, and this is the very sort of application misbehaviour that occurs.
Comparing the terminfo database entries for xterm-256color
and putty-256color
reveals what is happening with your â±Â Home and â²Â End keys:
% infocmp xterm-256color putty-256color|grep -F kend
kend: 'EOF', 'E[4~'.
% infocmp xterm-256color putty-256color|grep -F khome
khome: 'EOH', 'E[1~'.
%
As you can see, an application that is told that it is dealing with XTerm expects to receive (from the terminal) the control sequence âOH
for the â±Â Home key and the control sequence âOF
for the â²Â End key. But PuTTY actually sends the control sequences â[1~
and â[4~
(respectively) instead.
Your application, the Z shell, expecting the the XTerm keyboard control sequences (because you have erroneously told it that your terminal has the type xterm
), does not recognize the PuTTY control sequences, and in fact breaks them down into the vi
-mode commands to exit insert mode (â
) and swap the case of the current character (~
).
Further reading
- Where does the TERM environment variable default get set?
- Fish shell shows dark-grey "âà ½" characters in prompt
- https://unix.stackexchange.com/a/444270/5132
edited May 30 at 13:09
answered Jan 23 at 14:11
JdeBP
28.6k459134
28.6k459134
Thank you for the very useful information. After settingTERM
toputty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I starttmux
, the Home+arrow combos move by one word again...
â Gunee
Jan 24 at 9:48
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changingTERM
, you might get more consistent behavior by runningreset
.
â Thomas Dickey
Jan 24 at 10:22
Out of tmux,reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.
â Gunee
Jan 24 at 10:31
add a comment |Â
Thank you for the very useful information. After settingTERM
toputty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I starttmux
, the Home+arrow combos move by one word again...
â Gunee
Jan 24 at 9:48
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changingTERM
, you might get more consistent behavior by runningreset
.
â Thomas Dickey
Jan 24 at 10:22
Out of tmux,reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.
â Gunee
Jan 24 at 10:31
Thank you for the very useful information. After setting
TERM
to putty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I start tmux
, the Home+arrow combos move by one word again...â Gunee
Jan 24 at 9:48
Thank you for the very useful information. After setting
TERM
to putty-256-color
in putty, I could get Home and End to work as I expect. However the arrows still move by one word. Ctrl+arrow moves by one character though. And then, when I start tmux
, the Home+arrow combos move by one word again...â Gunee
Jan 24 at 9:48
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changing
TERM
, you might get more consistent behavior by running reset
.â Thomas Dickey
Jan 24 at 10:22
PuTTY's arrow/control-arrow switches the sent-sequence between normal and application modes. The difference you're commenting on has to do with how the terminal was initialized. After changing
TERM
, you might get more consistent behavior by running reset
.â Thomas Dickey
Jan 24 at 10:22
Out of tmux,
reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.â Gunee
Jan 24 at 10:31
Out of tmux,
reset
helped: arrows move by one char, Ctrl + arrows move by one word. Running tmux though, I can only get "move by one word" behaviour.â Gunee
Jan 24 at 10:31
add a comment |Â
up vote
0
down vote
As kindly pointed by JdeBP, my TERM
was wrongly set.
I was finally able to have everything working consistently with the following steps:
- Set terminal type in Putty to
putty
- Deactivate application mode for cursor and keypad in Putty
- Add the following lines to my
.tmux.conf
fileset -g default-terminal "$TERM"
to prevent tmux from usingscreen
by defaultset -g terminal-overrides "putty*:kLFT5=eOD:kRIT5=eOC:kUP5=eOA:kDN5=eOB:smkx@:rmkx@"
to have the Left and Right keys move by one char, instead of one word
add a comment |Â
up vote
0
down vote
As kindly pointed by JdeBP, my TERM
was wrongly set.
I was finally able to have everything working consistently with the following steps:
- Set terminal type in Putty to
putty
- Deactivate application mode for cursor and keypad in Putty
- Add the following lines to my
.tmux.conf
fileset -g default-terminal "$TERM"
to prevent tmux from usingscreen
by defaultset -g terminal-overrides "putty*:kLFT5=eOD:kRIT5=eOC:kUP5=eOA:kDN5=eOB:smkx@:rmkx@"
to have the Left and Right keys move by one char, instead of one word
add a comment |Â
up vote
0
down vote
up vote
0
down vote
As kindly pointed by JdeBP, my TERM
was wrongly set.
I was finally able to have everything working consistently with the following steps:
- Set terminal type in Putty to
putty
- Deactivate application mode for cursor and keypad in Putty
- Add the following lines to my
.tmux.conf
fileset -g default-terminal "$TERM"
to prevent tmux from usingscreen
by defaultset -g terminal-overrides "putty*:kLFT5=eOD:kRIT5=eOC:kUP5=eOA:kDN5=eOB:smkx@:rmkx@"
to have the Left and Right keys move by one char, instead of one word
As kindly pointed by JdeBP, my TERM
was wrongly set.
I was finally able to have everything working consistently with the following steps:
- Set terminal type in Putty to
putty
- Deactivate application mode for cursor and keypad in Putty
- Add the following lines to my
.tmux.conf
fileset -g default-terminal "$TERM"
to prevent tmux from usingscreen
by defaultset -g terminal-overrides "putty*:kLFT5=eOD:kRIT5=eOC:kUP5=eOA:kDN5=eOB:smkx@:rmkx@"
to have the Left and Right keys move by one char, instead of one word
answered Jan 25 at 9:59
Gunee
1086
1086
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f419068%2fusing-putty-left-and-right-keys-move-cursor-one-word-instead-of-one-char%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
You might want to include the output of your
zsh -v
in your question.â EightBitTony
Jan 23 at 13:51
zsh -v
traces have been added to this gist: gist.github.com/guneemwelloeux/34ee3943ac32847895dc4c57f74c5ff7. Careful though, the files are 6k lines long each, so the page is pretty heavy to load.â Gunee
Jan 24 at 10:40