2

I have an Ubuntu 11.04 server on Amazon EC2 which cannot display TUI interfaces correctly, like on Midnight Commander or tree.

corruption

I'm quite sure that this problem was not there when I set it up, and I suspect that it may have occurred since I did a apt-get dist-upgrade.

How can I fix this?

1
  • Gilles' answer is correct if you are using one of the terminal programs he recommends. If not, please edit your answer to specify which one you're trying to use. Setting your terminal program up to use Unicode line-drawing characters varies depending on that. Jan 9, 2012 at 22:51

1 Answer 1

5

The characters ─ in CP-1251 (an 8-bit character set that extends latin1) make up when interpreted in UTF-8. Evidently, your locales are not set up properly: the remote system thinks it is displaying on an UTF-8 terminal (UTF-8 is the de facto standard encoding in the Unix world), but your terminal is displaying in CP-1251 (are you running a terminal emulator under Windows?). You must fix this discrepancy.

My recommendation is to use a Unicode terminal. It's more capable, and Unicode (encoded in UTF-8) is the standard nowadays, outside legacy systems. Under Windows, I recommend mintty, or if you're combining a terminal emulator with ssh, PuTTY. Make sure to configure the terminal for Unicode (and use a font that has significant support for Unicode, which shouldn't be a issue as long as your Windows version is at least Windows XP).

If you're stuck with a non-Unicode terminal, set the remote system to use latin1. Make sure that the en_US.iso88591 locale is generated (check with locale -a, and run sudo locale-gen en_US.iso88591 if it doesn't appear in the list). Then add export LC_CTYPE=en_US.iso88591 in ~/.profile.

10
  • Thanks for the answer, but I am getting the same results with both PuTTY and SecureCRT. This is not happening with any other server and I am pretty sure that it was not previously happening on this one, when it was set up. I connect using the same settings with either client and just change the address and ssh key and this problem occurs. It also occurs when I ssh from a Debian server without this issue, through either client. However, it does not happen when I ssh from shellinabox running on another server. Do you have any idea what could be happening with this further information?
    – paradroid
    Jan 14, 2012 at 9:05
  • @paradroid I suspect your problem is that you changed your local configuration. Make sure your local terminal is set up to UTF8. Jan 14, 2012 at 14:14
  • But I used the same settings as I do for another server, which does not have the same problem, and even if I ssh from that server, I see the problem on the Ubuntu server. This happens with two different clients, but only on this Ubuntu server, but not from shellinabox on another server when connecting to the Ubuntu server through ssh. It just doesn't make any sense to me.
    – paradroid
    Jan 14, 2012 at 14:31
  • @paradroid Well, what clients have you tried, and what encoding are they set up for? What does locale -a show on the server? Jan 14, 2012 at 14:32
  • I found the encoding setting in PuTTY and set it to UTF-8. I connect to the Debian server, but now TUI interfaces on that are screwed up, with vertical lines being replaced with x and horizontal lines being replaced with q. When I connect to the Ubuntu server through the Debian server, the TUI interface on it looks fine. It's making more sense now, but Debian does not want to have UTF-8 as the remote character set, while Ubuntu requires it, it seems. Hmmnn.
    – paradroid
    Jan 14, 2012 at 14:58

You must log in to answer this question.

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