In some programs, such as htop the lines and frames are not displayed correctly. Instead, they are displayed as - and /.

enter image description here

But on another machine, they are displayed correctly as proper lines:

enter image description here

I am not sure if this is a terminal issue, or if perhaps some package is necessary.

In case it is relevant: My system is Debian Wheezy, my interpreter is bash and my terminal emulator is gnome-terminal

  • Have you tried changing the font used by the terminal?
    – goldilocks
    Commented Oct 26, 2013 at 13:23
  • 3
    That would be a possible solution if placeholder characters like a boxes or question marks were in place of the Unicode characters, but his example shows htop displaying ASCII characters. However, if the default terminal font is non-Unicode, then the encoding is likely also, so I've added that to my answer.
    – raehik
    Commented Oct 27, 2013 at 15:25

2 Answers 2


Your top example is running with a non-Unicode locale (i.e. ASCII). Check your $LANG environment variable (try export | grep LANG); you will most likely not find a .UTF-8 suffix. Try adding it:

export LANG=$LANG.UTF-8

Your other example is running with a UTF-8 locale, which should be the default for recent shells. It seems htop detects your locale and displays either ASCII or Unicode characters - so in the bottom picture, you get nice Unicode characters, while with ASCII you get some pretty makeshift ones. I'd suggest changing the locale of the top picture's machine to a Unicode one (see Locale - Debian Wiki).

If that doesn't work, it might be that your terminal emulator is the problem. The default encoding could be non-Unicode. Change the default encoding of your terminal emulator to UTF-8 (in xfce4-terminal I found it in the Advanced tab). If you can't, it might be that your current font doesn't support Unicode: try changing your font to a Unicode one.

[Strangely, I found once I'd changed my locale to ASCII once in a shell session, htop always displays the ASCII characters, even after changing it back. That might be your issue, if for some reason you are changing your locale in your shell occasionally.]


The odd thing is that htop uses ncurses, which can draw lines with/without Unicode. However, looking at the source-code in CRT.c shows the explanation:

   if(strcmp(nl_langinfo(CODESET), "UTF-8") == 0)
      CRT_utf8 = true;
      CRT_utf8 = false;

   CRT_treeStr =
      CRT_utf8 ? CRT_treeStrUtf8 :

and the CRT_treeStrUtf8 value is

const char *CRT_treeStrUtf8[TREE_STR_COUNT] = {
   "\xe2\x94\x80", // TREE_STR_HORZ ─
   "\xe2\x94\x82", // TREE_STR_VERT │
   "\xe2\x94\x9c", // TREE_STR_RTEE ├
   "\xe2\x94\x94", // TREE_STR_BEND └
   "\xe2\x94\x8c", // TREE_STR_TEND ┌
   "+",            // TREE_STR_OPEN +
   "\xe2\x94\x80", // TREE_STR_SHUT ─

However, ncurses (any curses implementation) has portable symbols for these which do not rely upon whether the encoding is UTF-8 or not. Some applications (such as dialog's --ascii-lines option) provide an option for using ASCII line-drawing, but an application that does not even attempt to use the line-drawing provided in ncurses is not making effective use of the library.

In short, when you come across a program that behaves like that, you should report it as a bug to the developers.

Further reading:

  • While it did not directly solve my problem (setting LANG / LC_ALL enables the expected Unicode line drawing chars in htop), this is very interesting. Thanks for taking the time to explain it!
    – wrksprfct
    Commented Jul 21, 2016 at 14:19

You must log in to answer this question.

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