Shell Integration dings on PuTTY
I installed the latest shell integration on a remote systems. It works fine when I SSH in with iTerm2, however, when I SSH into it using PuTTY (v0.67) on Windows, the PROMPT_COMMAND causes every command to "ding" (bell) in PuTTY.
In particular, it is because of the function iterm2_end_osc: a print of a "\007" is a bell and PuTTY by default will sound the bell for this.
By default PuTTY will not sound a bell for a \007 in the prompt_command, it is just something with iterm2's function. E.g. PROMPT_COMMAND='echo -ne "\033]0;
Activity
Milestone changed to Ship 3.0
I tried switching it, and it had some strange artifacts on PuTTY (characters appearing that shouldn't).
Looking at it more closely, it is because the \007 comes after a the return (\r) in the "printf "133;C;\r"" that PuTTY will sound a bell. If I remove the \r from the printf, the bell does not sound in PuTTY. (And Shell integration with iTerm "appears" to continue working, but that return might be of some importance for something I am not testing.)
PS: The bell not only sounds with Bash, but also on the tcsh integration with the \r in the "alias _iterm2_print_between_prompt_and_exec 'printf "133;C;\r"'". Have not tried with other shell's, but assume similar results.
Does removing the
\rreturn make everything OK with PuTTY? Or do we need remove the return and also change\\007to\033\0134? The return isn't very important (it's there to fix issue #3866 (closed), which is less significant that spamming PuTTY).-
I filed the following bug against PuTTY:
PuTTY version: PuTTY (v0.67) Platform: Windows Protocol: SSH Bug: An OSC sequence that contains a carriage return (\r) prior to ST is parsed improperly. PuTTY thinks the carriage return ends the OSC code, but it should not. The VT500's operation is described nicely here: http://www.vt100.net/emu/vt500_parser.png As you can see, all control characters other than CAN, SUB, and ESC should be ignored. It's a little clearer than ECMA-48 which says: 8.3.89 OSC - OPERATING SYSTEM COMMAND Notation: (C1) Representation: 09/13 or ESC 05/13 OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system. By either interpretation, a carriage return should be allowed. To reproduce, in bash: echo -e '\033]0;foo\r\a' This should not beep, but in PuTTY it does. In practice it is an issue because an OSC sequence issued from zsh's precmd or its equivalent in others shells (i.e., after a command is entered but before it executes) makes the TTY line driver think the cursor is not on the first column (line drivers don't speak OSC, apparently). This breaks how TAB is handled when it is the first character of output from the command. This can be worked around by putting a carriage return just prior to ST. I admit this is obscure, but so far the only terminal I've found that exhibits this behavior is PuTTY. All others either swallow \r or are horribly broken with unrecognized OSC sequences. For all the gory details, see https://gitlab.com/gnachman/iterm2/issues/3866 and https://gitlab.com/gnachman/iterm2/issues/4437 Patch for terminal.c: 4396,4406c4396 < /* < * This OSC stuff is EVIL. It takes just one character to get into < * sysline mode and it's not initially obvious how to get out. < * So I've added CR and LF as string aborts. < * This shouldn't effect compatibility as I believe embedded < * control characters are supposed to be interpreted (maybe?) < * and they don't display anything useful anyway. < * < * -- RDB < */ < if (c == '\012' || c == '\015') { --- > if (c == '\030' || c == '\032') {
