New answers tagged

0

you are using a wrong order: export=en_US.utf-8 this should be: export LC_ALL=en_US.utf-8 or: export LANG=en_US.utf-8 Anyway, as the Debian wiki says, the use of LC_ALL is discouraged as it only lasts while session (i.e: an open terminal session). You could add it to a startup script, but this is discouraged again by Debian's wiki. If you just want ...


1

The same exact thing happened to me. Building on what Thomas said above, I was able to fix it by uncommenting en_US.UTF-8 UTF-8 in my /etc/locale.gen file (previously none of the lines had been uncommented), then running locale-gen.


1

Perhaps your upgrade replaced the locale alias you were using and did not provide a useful upgrade path to the new name(s). You can regenerate locale information on the server, but keep in mind that the problem may be in your /etc/locale.gen or locale.conf file. Further reading: Locale (Arch wiki) Why is almost every program complaining about my locale? ...


2

I came across this in 2016. A single TTF/OTF font is never going to cover all utf-8 characters. There is a hard limit of 65535 glyphs in a font, and over 1 million utf-8 glphys. You will need to use a font-family for this to work. A good font-family is the noto font family: https://www.google.com/get/noto/


0

Some of the comments suggested ncurses as a possible solution. There are pros/cons to that: ncurses is useful for drawing text while moving about the screen (either full-screen, or a full-line using filter). OP's example prints a fragment of a single line, and the discussion gave no clues whether this was a typical use, or part of something more ...


1

It turns out, that the terminal locales were setup somehow wrong. My .bashrc had a export LC_ALL=C. > locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" ... LC_IDENTIFICATION="C" LC_ALL=C After removing LC_ALL=C I get this: > locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC=en_US.UTF-8 LC_TIME=en_GB.UTF-8 ...



Top 50 recent answers are included