Using putty, Left and Right keys move cursor one word, instead of one char

The name of the pictureThe name of the pictureThe name of the pictureClash 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







share|improve this question






















  • 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














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







share|improve this question






















  • 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












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







share|improve this question














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









share|improve this question













share|improve this question




share|improve this question








edited Jan 24 at 9:56

























asked Jan 23 at 12:58









Gunee

1086




1086











  • 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
















  • 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















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










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





share|improve this answer






















  • 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










  • 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

















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:



  1. Set terminal type in Putty to putty

  2. Deactivate application mode for cursor and keypad in Putty

  3. Add the following lines to my .tmux.conf file


    • set -g default-terminal "$TERM" to prevent tmux from using screen by default


    • set -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






share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    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






























    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





    share|improve this answer






















    • 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










    • 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














    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





    share|improve this answer






















    • 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










    • 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












    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





    share|improve this answer














    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






    share|improve this answer














    share|improve this answer



    share|improve this answer








    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 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










    • 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











    • 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















    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












    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:



    1. Set terminal type in Putty to putty

    2. Deactivate application mode for cursor and keypad in Putty

    3. Add the following lines to my .tmux.conf file


      • set -g default-terminal "$TERM" to prevent tmux from using screen by default


      • set -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






    share|improve this answer
























      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:



      1. Set terminal type in Putty to putty

      2. Deactivate application mode for cursor and keypad in Putty

      3. Add the following lines to my .tmux.conf file


        • set -g default-terminal "$TERM" to prevent tmux from using screen by default


        • set -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






      share|improve this answer






















        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:



        1. Set terminal type in Putty to putty

        2. Deactivate application mode for cursor and keypad in Putty

        3. Add the following lines to my .tmux.conf file


          • set -g default-terminal "$TERM" to prevent tmux from using screen by default


          • set -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






        share|improve this answer












        As kindly pointed by JdeBP, my TERM was wrongly set.



        I was finally able to have everything working consistently with the following steps:



        1. Set terminal type in Putty to putty

        2. Deactivate application mode for cursor and keypad in Putty

        3. Add the following lines to my .tmux.conf file


          • set -g default-terminal "$TERM" to prevent tmux from using screen by default


          • set -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







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 25 at 9:59









        Gunee

        1086




        1086






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?