How to solve the problem of entering Russian text in the KDE console?

Question

Internationalization and localization

Kubuntu 14.04 system with configured Russian locale stopped working entering Russian into the console.

[email protected]:~$ uname -a
Linux asim-T410 3.16.0-70-generic #90~14.04.1-Ubuntu SMP Wed Apr 6 22:56:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[email protected]:~$ cat /etc/issue.net
Ubuntu 14.04.4 LTS
[email protected]:~$ plasma-desktop -v
Qt: 4.8.6
KDE: 4.13.3
Оболочка Plasma: 4.11.11
[email protected]:~$ echo $TERM
xterm
[email protected]:~$ locale
LANG=ru_RU.UTF-8
LANGUAGE=ru:en
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC=ru_RU.UTF-8
LC_TIME=ru_RU.UTF-8
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY=ru_RU.UTF-8
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER=ru_RU.UTF-8
LC_NAME=ru_RU.UTF-8
LC_ADDRESS=ru_RU.UTF-8
LC_TELEPHONE=ru_RU.UTF-8
LC_MEASUREMENT=ru_RU.UTF-8
LC_IDENTIFICATION=ru_RU.UTF-8
LC_ALL=

The Latin alphabet is entered correctly, and when switching to Cyrillic and entering the first characters, the previously entered Latin characters disappear, and a colon with a question mark in inverted colors appears at the beginning of the line.

:�

If at the same time you continue entering in the Russian layout, Russian characters will be printed.
[email protected]:~$ :�кириллические символы
If you delete them together with question marks and colons, the previously entered Latin characters will appear in the line.
Other applications work with the Russian language as expected. Previously, the console worked, but at some point it stopped. Other terminal emulators behave similarly. Tried konsole, yakuake, gnome-terminal. Inserting Russian characters written in another application gives the same effect - appears:�
Cyrillic output works as expected.

[email protected]:~$ kj
kj: команда не найдена

With this behavior, you cannot move to a directory or perform an operation on files containing Cyrillic characters in names or paths. Please help me figure it out.

Answer 1

dimmidrol, It 's not about the fonts. However, thanks! Your comment prompted a comparison of the fonts of different bash profiles, as well as different users of the system. It turned out that if you run the terminal as a superuser via kdesu konsole, the described problem is absent, the layout is switched, the Cyrillic alphabet is printed as it should. Comparison of the two users' terminal-related configuration files revealed a strange extra line in the main user's .inputrc file:
Whatever that means, removed - the problem is gone! HURRAH!!!

Answer 2

What are the fonts for the terminal? There was once such a problem, I installed the fonts (only it was a long time ago, I don’t remember which ones) and the problem disappeared.

Answer 3

I have the same problem on Debian 8, (KDE or GNOME - it doesn't matter!)
Cyrillic is necessary, in particular, for working with the database (selection by last name, address ...)
I have this /etc/inputrc :

# /etc/inputrc - global inputrc for libreadline
# See readline(3readline) and `info rluserman' for more information.

# Be 8 bit clean.
set input-meta on
set output-meta on

# To allow the use of 8bit-characters like the german umlauts, uncomment
# the line below. However this makes the meta key not work as a meta key,
# which is annoying to those which don't need to type in 8-bit characters.

# set convert-meta off

# try to enable the application keypad when it is called.  Some systems
# need this to enable the arrow keys.
# set enable-keypad on

# see /usr/share/doc/bash/inputrc.arrows for other codes of arrow keys

# do not bell on tab-completion
# set bell-style none
# set bell-style visible

# some defaults / modifications for the emacs mode
$if mode=emacs

# allow the use of the Home/End keys
"\e[1~": beginning-of-line
"\e[4~": end-of-line

# allow the use of the Delete/Insert keys
"\e[3~": delete-char
"\e[2~": quoted-insert

# mappings for "page up" and "page down" to step to the beginning/end
# of the history
# "\e[5~": beginning-of-history
# "\e[6~": end-of-history

# alternate mappings for "page up" and "page down" to search the history
# "\e[5~": history-search-backward
# "\e[6~": history-search-forward

# mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

$if term=rxvt
"\e[7~": beginning-of-line
"\e[8~": end-of-line
"\eOc": forward-word
"\eOd": backward-word
$endif

# for non RH/Debian xterm, can't hurt for RH/Debian xterm
# "\eOH": beginning-of-line
# "\eOF": end-of-line

# for freebsd console
# "\e[H": beginning-of-line
# "\e[F": end-of-line

$endif

those. the line specified by the author is set convert-metainitially commented out.
Various variations "at random" with the on / off / # parameters did not lead to anything.
Interestingly, on a Debian 7 machine with a similar /etc/inputrc , there is no problem.
planning
But, if someone tells me the reason / solution - I will be grateful.

Answer 4

Adding a line to the /etc/inputrc file helped: set convert-meta off (responsible for canceling the cut of 8 bits in the input characters).
True, there was a bug: when entering Russian letters, then you can delete twice as many characters, but this does not interfere with normal operation)