GNU/Linux >> Znalost Linux >  >> Linux

Při použití Putty se Alt-left/right liší, když se Byobu spouští automaticky z profilu?

Při zahájení relace na, alespoň v mém případě, na počítačích debian a Ubuntu s Putty z počítače s Windows, alt-left/right funguje jako pohyb po slovu na příkazovém řádku. (Často toho lze dosáhnout také na systémech Linux pomocí ctr-left/right ).

Jakmile jsem však začal používat Byobu, a nastavit automatické spouštění Byobu (pomocí nabídky F9), alt-left/right už nefunguje. Místo toho při výstupu nezpracovaných znaků pomocí Ctrl-V ukazuje,

 ^[[1;3C

— při odesílání alt-right . Zatímco když se byobu nespustí automaticky při přihlášení, ale po přihlášení se spustí ručně, vydedukoval jsem, že odešle,

^[^[[C

Což je zachyceno výchozí konfigurací inputrc a následně je přeloženo jako pohyb po slovech.

Jaký mechanismus mezi Putty, hostitelem/terminálem/byobu je ve hře, aby se dosáhlo tohoto rozdílu v přijatých příkazech?

Přijatá odpověď:

byobu je jen obal kolem tmux, který je zodpovědný za chování, které vidíte. tmux se pokouší přeložit „klíče“ do sekvence znaků, kterou by xterm zakódoval upravené speciální klíče. V návodu je to zdokumentováno:

         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.

i když v nových/nedávných verzích je údajně výchozí nastavení zapnuto . To odhalilo problém, který je vidět v této zprávě o potvrzení:

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.

Linux
  1. Barva teče hned při psaní vlastního skriptu v Byobu?

  2. Zabránit spuštění Tmux na Ssh?

  3. Připojte se k Linuxu z Windows pomocí PuTTY

  1. Při odesílání e-mailu pomocí příkazu mail zadejte od uživatele

  2. Automatizace spouštění příkazů na Linuxu z Windows pomocí PuTTY

  3. Nelze odpojit podřízený proces, když je hlavní proces spuštěn ze systemd

  1. Kolik ti bylo let, když jsi poprvé začal používat Linux?

  2. Windows – Jak zabránit Windows v přepsání Grub při použití stroje s duálním spouštěním?

  3. Mírné zpoždění při přepínání režimů ve vim pomocí tmux nebo obrazovky