Bei Verwendung von Putty ist Alt-Links/Rechts anders, wenn Byobu automatisch aus dem Profil gestartet wird?

Beim Starten einer Sitzung zu, zumindest in meinem Fall, Debian- und Ubuntu-Rechnern mit Putty von einem Windows-Rechner, alt-left/right funktioniert wie das Bewegen pro Wort auf der Befehlszeile. (Oft wird dies auch auf Linux-Systemen mit ctr-left/right erreicht ).

Als ich jedoch anfing, Byobu zu verwenden, und Stellen Sie Byobu so ein, dass es automatisch startet (über das F9-Menü), alt-left/right funktioniert nicht mehr. Stattdessen bei der Ausgabe der Rohzeichen mit Ctrl-V es zeigt,

 ^[[1;3C

— beim Senden von alt-right . Wenn hingegen byobu beim Einloggen nicht automatisch gestartet wird, sondern nach dem Einloggen manuell gestartet wird, habe ich geschlussfolgert, dass es sendet,

^[^[[C

Was von einer Standard-inputrc-Konfiguration abgefangen wird und folglich übersetzt wird, um sich wortweise zu bewegen.

Welcher Mechanismus zwischen Putty, dem Host/Terminal/Byobu ist im Spiel, um diesen Unterschied in den empfangenen Befehlen auszumachen?

Akzeptierte Antwort:

byobu ist nur ein Wrapper um tmux, der für das Verhalten verantwortlich ist, das Sie sehen. tmux versucht „keys“ in die Zeichenfolge zu übersetzen, die xterm modifizierte Sondertasten kodieren würde. Im Handbuch ist das dokumentiert:

         xterm-keys [on | off]
                 If this option is set, tmux will generate xterm(1) -style
                 function key sequences; these have a number included to
                 indicate modifiers such as Shift, Alt or Ctrl.  The
                 default is off.

obwohl in neuen/aktuellen Versionen Berichten zufolge die Standardeinstellung an ist . Das hat ein Problem aufgedeckt, das in dieser Commit-Nachricht zu sehen ist:

commit d52f579fd5e7fd21d7dcf837780cbf98498b10ce
Author: nicm <nicm>
Date:   Sun May 7 21:25:59 2017 +0000

    Up to now, tmux sees \033\033[OA as M-Up and since we turned on
    xterm-keys by default, generates \033[1;3A instead of
    \033\033[OA. Unfortunately this confuses vi, which doesn't understand
    xterm keys and now sees Escape+Up pressed within escape-time as Escape
    followed by A.

    The issue doesn't happen in xterm itself because it gets the keys from X
    and can distinguish between a genuine M-Up and Escape+Up.

    Because xterm can, tmux can too: xterm will give us \033[1;3A (that is,
    kUP3) for a real M-Up and \033\033OA for Escape+Up - in fact, we can be
    sure any \033 preceding an xterm key is a real Escape key press because
    Meta would be part of the xterm key instead of a separate \033.

    So change tmux to recognise both sequences as M-Up for its own purposes,
    but generate the xterm version of M-Up only if it originally received
    the xterm version from the terminal.

    This means we will return to sending \033\033OA instead of the xterm key
    for terminals that do not support xterm keys themselves, but there is no
    practical way around this because they do not allow us to distinguish
    between Escape+Up and M-Up. xterm style escape sequences are now the de
    facto standard for these keys in any case.

    Problem reported by [email protected] and subsequently by Cecile Tonglet in GitHub
    issue 907.