Ao usar putty, alt-left / right é diferente quando byobu é iniciado automaticamente a partir do perfil

Question

Ao iniciar uma sessão para, no meu caso, pelo menos, máquinas debian e Ubuntu com Putty de uma máquina Windows, alt-left/right funciona como movimentação por palavra na linha de comando. (Muitas vezes isso também é alcançado em sistemas Linux com ctr-left/right ).

No entanto, assim que comecei a usar o Byobu, e definiram o Byobu para iniciar automaticamente (usando o menu F9), o alt-left/right não funciona mais. Em vez disso, ao exibir os caracteres brutos usando Ctrl-V ,

 ^[[1;3C

- ao enviar alt-right . Considerando que, quando byobu não é iniciado automaticamente quando logar, mas é iniciado manualmente uma vez logado, deduzi que ele envia,

^[^[[C

Que é capturado por uma configuração inputrc padrão e, consequentemente, é traduzido para mover por palavra.

Qual mecanismo entre Putty, o host / terminal / byobu está em jogo, para fazer essa diferença nos comandos recebidos?

    

Answer 1

byobu é apenas um wrapper em torno do tmux, que é responsável pelo comportamento que você está vendo. O tmux está tentando traduzir "chaves" na seqüência de caracteres que o xterm codifica chaves especiais modificadas. No manual, isso está documentado:

         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.

embora em versões novas / recentes, o padrão é em . Isso expôs um problema, visto nesta mensagem de confirmação:

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

    Up to now, tmux sees 33[OA as M-Up and since we turned on
    xterm-keys by default, generates 3[1;3A instead of
    33[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 3[1;3A (that is,
    kUP3) for a real M-Up and 33OA for Escape+Up - in fact, we can be
    sure any 3 preceding an xterm key is a real Escape key press because
    Meta would be part of the xterm key instead of a separate 3.

    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 33OA 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 jsing@ and subsequently by Cecile Tonglet in GitHub
    issue 907.