Running a brand new Ubuntu 16.04 and a Debian 8 server. Trying to connect via ssh and getting the following strange terminal output. I refer to the rectangles with the numbers in it.

The problem with the language settings was introduced by myself trying to solve the just mentioned problem since I assumed some encoding problems to be responsible. After 3h of debugging I need your help!

Maybe it's just a missing library? It is hard searching for such graphical problems...

enter image description here

local@local:~$ ssh dummy@server

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jul  9 17:22:43 2016 from x590c3909.dyn.telefonica.de
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
]1337;RemoteHost=dummy@server]1337;CurrentDir=/home/patrick]1337;ShellIntegrationVersion=2;shell=bash]133;C;]133;D;0]1337;RemoteHost=dummy@server]1337;CurrentDir=/home/patrick]133;Adummy@server:~$ ]133;B

echo $PS1 output:

echo $PS1
]133;C;\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$

echo $TERM output:

echo $TERM

Edit: "locale" - warning fixed by this answer.

  • please add echo $PS1 and echo $TERM to the post Commented Jul 9, 2016 at 16:16
  • I will check on your links. However I already checked some language related posts and did not succeed. Added the code now...
    – pat-s
    Commented Jul 9, 2016 at 16:16
  • echo $TERM too please Commented Jul 9, 2016 at 16:22
  • 1
    No - see egmont's comment in this question. It's a case of gnome-terminal meeting iTerm2 and misbehaving. Commented Jul 9, 2016 at 17:12
  • 1
    There's likely some script which you are using that's for iTerm2 (the 1337 code). Terminator is one of several skins over VTE (the real terminal emulator for gnome-terminal), and depending on versions used, they have the same set of bugs. Commented Jul 9, 2016 at 17:32

2 Answers 2


What your terminal is doing

The "rectangles with the numbers in [them]" are the way that your terminal emulator is displaying a terminal control sequence to you, because it doesn't recognize that sequence. Specifically:

  • There is an ECMA-48 control character (in the C1 group, for the technical) named Operating System Command, abbreviated OSC. It has the Unicode value U+009D.
  • ECMA-48 defines a mechanism where characters in the C1 group, which require a fully clean 8-bit communications path in order to be transmitted, can be represented by an escape sequence that uses only characters with values less than U+0080 (128). These 7-bit aliases enable the use of C1 control characters on transmission paths that are not 8-bit clean. Ironically, the world has been largely 8-bit clean for decades, now.

    You'll most likely know one of these 7-bit aliases that is very common: ESC [ instead of the CSI control character (U+009B). The OSC control character has ESC ] as a 7-bit alias.

  • Something on the far end of your SSH connection is expecting your terminal to understand control sequences that begin with OSC. It is transmitting them using the 7-bit alias.
  • Your terminal doesn't fully implement ECMA-48. It's seeing ESC ] and just treating it as an ESC character followed by an ] character. And that's what it is printing.
  • But it doesn't have a glyph for the ESC character. So it's falling back to the conventional trick of displaying characters that it doesn't have a glyph for as a box with the hexadecimal value of the (lowest 16 bits of the) Unicode code point in it. If you look closely, you'll see the numbers 00 and 1B in the box, for U+001B, the code point for the ESC character.
  • It also doesn't correctly deal with the "spacing" of what it has printed for the ESC, i.e. the space that it takes on the screen, which is actually two character widths. So after printing the box it doesn't advance the output position enough. It then prints the ] over the top of the right-hand half of the box, as you can see.

Why it has been told to do that

Several terminal emulators recognize OSC as a control character sequence introducer. There's a standard form for it, even. ECMA-48 § 5.6 defines "control strings" begun with OSC and terminated with ST (U+009C, String Terminator). What is in the control string is terminal-type specific. For example: You'll see from its doco that xterm implements such control strings, for setting fonts and window titles.

However, the form of the control sequence in this case is not that of xterm. Rather, it is


This is the form for OSC control sequences that is understood by iTerm2. iTerm2 defines a set of control sequences introduced by OSC that are distinctly non-standard and idiosyncratic to iTerm2. They do not adhere to the ECMA-48 control string specification but terminate the control string with BEL (U+0007) rather than with ST as the standard says. Strictly speaking, that's a control string that isn't ever terminated, since any characters other than SOS and ST are permitted in the contents of a control string; and is one that with a conformant terminal emulator effectively just stops display, as the terminal simply accrues all further output as a control string.

(The terminal emulator that is built in to the Linux kernel also doesn't implement standard OSC control strings. The xterm doco notes that it has bodges to support broken applications that use the non-conformant Linux kernel terminal emulator or iTerm2 forms. The form here is definitely iTerm2's, not that of the Linux kernel terminal emulator, though.)

When you are using iTerm2 from your Macintosh, whatever is on the other end of the SSH connection is quietly sending iTerm2 control sequences to your terminal emulator to tell it stuff like what your shell is, what your working directory is, who you are, when you start editing at a shell prompt, when you start executing a command, and so forth.

On the remote system, you have hardwired the terminal type. You've made it operate under the assumption that you're always talking to it with iTerm2. But you are now talking to it using Terminator running on Ubuntu, a different terminal emulator that has a different set of control sequences.

In fact, the output even tells you this:


You've installed the iTerm2 "Shell Integration" for the Bourne Again shell on your remote system. Looking at it, it is pretty bad at checking that iTerm2 is actually the terminal that it is speaking to.

So disable/uninstall it.

Further reading

  • Control Functions for Coded Character Sets. ECMA-48. ECMA International.
  • console_codes. Linux manual pages. § 4. 2015.
  • Matthew Freeman, George Nachman, and James A. Rosen. Proprietary Escape Codes. iTerm2 documentation.
  • Matthew Freeman, George Nachman, and James A. Rosen. Shell Integration. iTerm2 documentation.
  • +1, IMO fancy prompt strings (and PROMPT_COMMAND) just cause problems, especially if you're routinely working on multiple different systems. IMO, an empty PROMPT_COMMAND and PS1='\u@\h:\w\$ ' (or '\u@\h \W\$ ' if you don't want the full path) is ideal and will never mess up your terminal or overwrite the terminal or tab's title.
    – cas
    Commented Jul 10, 2016 at 0:15

Try prefixing ssh command with a different LC_ALL, e.g.

LC_ALL=C ssh dummy@server

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .