1

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

Gunee
  • 123
  • You might want to include the output of your zsh -v in your question. – EightBitTony Jan 23 '18 at 13:51
  • zsh -v traces have been added to this gist: https://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 '18 at 10:40

2 Answers2

2

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

JdeBP
  • 68,745
  • 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 '18 at 09:48
  • 1
    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 '18 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 '18 at 10:31
1

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
Gunee
  • 123