Right now, it looks like this:
Debian – How to Enable UTF-8 Support in the Linux Console
consoledebianunicode
Related Solutions
That terminal is called the Linux console, or sometimes a “vt” (short for virtual terminal). The terminology can be confusing, especially since it's used inconsistently and sometimes incorrectly. You can find more information on terminology by reading What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'?.
The Linux console supports user-configured fonts, so the answer to your question is “whatever the user set up”. The utility to change the font is consolechars
, part of the Linux console tools. Only 8-bit fonts are supported by the hardware, though you can partly work around this by supporting unicode-encoded output but only having 256 glyphs (other characters are ignored). Read the lct documentation (online as of this writing, it should be included in your distribution's package) for more information.
If you use the Linux framebuffer, you can have proper unicode support, either directly or through fbterm.
The half-block characters are included in IBM code page 437, which is supported in ROM most PC video adapters. Depending on what characters you need, this may be enough.
Note that very few people use the Linux console these days. Some people cannot use it for various reasons (not running Linux, running on a remote X terminal, having a video adapter where text mode is buggy, …). I don't recommend spending much energy on supporting it.
When Vim reads an existing file, it tries to detect the file encoding. When writing out the file, Vim uses the file encoding that it detected (except when you tell it differently). So a file detected as UTF-8 is written as UTF-8, a file detected as Latin-1 is written as Latin-1, and so on.
By default, the detection process is crude. Every file that you open with Vim will be assumed to be Latin-1, unless it detects a Unicode byte-order mark at the top. A UTF-8 file without a byte-order mark will be hard to edit because any multibyte characters will be shown in the buffer as character sequences instead of single characters.
Worse, Vim, by default, uses Latin-1 to represent the text in the buffer. So a UTF-8 file with a byte-order mark will be corrupted by down-conversion to Latin-1.
The solution is to configure Vim to use UTF-8 internally. This is, in fact, recommended in the Vim documentation, and the only reason it is not configured that way out of the box is to avoid creating enormous confusion among users who expect Vim to operate basically as a Latin-1 editor.
In your .vimrc
, add set encoding=utf-8
and restart Vim.
Or instead, set the
LANG
environment variable to indicate that UTF-8 is your preferred character encoding. This will affect not just Vim but any software which relies onLANG
to determine how it should represent text. For example, to indicate that text should appear in English (en
), as spoken in the United States (US
), encoded as UTF-8 (utf-8
), setLANG=en_US.utf-8
.
Now Vim will use UTF-8 to represent the text in the buffer. Plus, it will also make a more determined effort to detect the UTF-8 encoding in a file. Besides looking for a byte-order mark, it will also check for UTF-8 without a byte-order mark before falling back to Latin-1. So it will no longer corrupt a file coded in UTF-8, and it should properly display the UTF-8 characters during the editing session.
For more information on how Vim detects the file encoding, see the
fileencodings
option in the Vim
documentation.
For more information on setting the encoding that Vim uses
internally, see the encoding
option.
If you need to override the encoding used when writing a file back
to disk, see the fileencoding
option.
Best Answer
Sure (it's limited on the number of glyphs, but it seems your locale is using UTF-8 encoding).
I use this for testing:
and (calling it "utf8"), "utf8 on" turns the encoding on.
Using the example given with
pstree
, here is an example after running the script (before, the same sort of output as in the question):As noted in a comment, there's a script
unicode_start
which does more, but all that is needed to address the question posed is the small script used as an example.Addressing a different comment: At least on my system (and in the screenshot shown in the question), all of the characters used by
pstree
are supplied in the 512-glyph font used by default for Unicode support in the Linux console.Further reading: