Откуда взялась эта tt_RU.UTF-8 ?

В /etc/locale.conf загляни.

Погрепай уже /etc и ~!

Небось, сам запихнул куда-нибудь в /etc/profile.d/ или ~/.bashrc, да забыл...

Может в ДЕ выставил вместо русского? А что с ней не так, кстати? И чем английский не устроил? Разве что имперские форматы чисел выкинуть, а то они слишком аутестичные.

eselect показывает, что локаль выставлена en_US.utf8

# eselect locale list
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
Available targets for the LANG variable:
  [1]   C
  [2]   POSIX
  [3]   en_US
  [4]   en_US.iso88591
  [5]   en_US.utf8 *
  [ ]   (free form)

Русскую локаль не ставил, тем более кривую tt_RU, пользуюсь только английским, мне этого достаточно.

GUI тоже весь англоязычный, нигде русского нет. Только формат даты/времени/currency. Всё.

/etc/locale.conf отсутствует, сейчас попробую погрепать /etc

Покажи вывод locale

А что за tt_RU вообще?
Татарский?

localhost /etc # grep -nr "*tt_RU.UTF-8*" /etc
localhost /etc # grep -nr "*tt_RU.UTF-8*" /root

Оба грепа пустые

Не знаю, что это за tt, гугол тоже не знает, татарский или тарабарский или ещё какой...

Ты /etc погрепал?

Покажи выхлоп

grep -R tt_RU /etc 2>/dev/null

Тогда грепай в ~/.bashrc и ~/.bash_profile. Ну или что ты там используешь.

дженту это полный контроль над системой, говорили они

9/10 софта не будет нормально работать с ней

Нет, будет. Не будет работать (как минимум, из коробки) только 1/10, которая заточена конкретно под UTF-8.

А такой софт как, например, nano спокойно собирается с --disable-utf8.

grep -R tt_RU /etc 2>/dev/null тоже пустой

.bashrc и .bash_profile у рута вообще отсутствуют, у пользователя:

~/.bashrc

# /etc/skel/.bashrc
#
# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output.  So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
	# Shell is non-interactive.  Be done now!
	return
fi


# Put your fun stuff here.

~/.bash_profile:

# /etc/skel/.bash_profile

# This file is sourced by bash for login shells.  The following line
# runs your .bashrc and is recommended by the bash info pages.
if [[ -f ~/.bashrc ]] ; then
	. ~/.bashrc
fi

В Gentoo локаль пишется в /etc/env.d/02locale

я там уже смотрел

# cat /etc/env.d/02locale
# Configuration file for eselect
# This file has been automatically generated.
LANG="en_US.utf8"
LC_COLLATE="C"

Посмотри еще в /etc/profile.env

Консольный софт не будет работать нормально. Я пробовал, баги лезут.

Да, он самый. Но это фактически мёртвая локаль, так как переводов на неё в природе, кажется, не существует.

Что ж ты брешешь-то?

Как раз с хрюникодом консольный софт и не будет работать. Скажем, надо мне из текста выделить подстроку с N-го по M-й символ, я это с легкостью при помощи cut сделаю или даже просто dd запущу. А с хрюникодом сначала придется выдумывать, как в баше вычислить смещение этого N-го символа в байтах.

Ох и дебилы эти придурки, выдумавшие хрюникод в консоль пихать...

Хм, чувак, а не заходишь ли ты на эту машину по ssh с машины, у которой татарская локаль? Учитывая то, что у тебя в /etc/profile.d пусто насчет локали, а у рута нет ~/.bashrc и ~/.bash_profile (почему, кстати?), вполне может подхватиться «родительская» локаль...

Эдик не палится.

Это диверсия. Но пока ещё никому во всём интернете не удалось найти место её возникновения.

Примеры такого софта в студию. Весь основной консольный софт продолжает работать с однобайтными кодировками.

Я помню ту твою однобайтную программу, если это это основной софт, то да, конечно. Только у неё недостаток, с юникодом она не работает никак? Сейчас существование систем без юникода просто не предусмотрено большинством разработчиков, следовательно баги и косяки. Примеры на вскидку не вспомню просто потому что мне не интересно было и сейчас я не вижу смысла обсуждать очевидное.

Там выше утверждение быле не про невозможность работы с юникодом, а про невозможность работы с однобайтными кодировками.

Основной софт - это ls, cp, mv, rm, cat, sed, awk, grep, lynx, vim, ed, mutt, gcc, ld, perl, python3, ruby,... и т.д. И он продолжает работать с однобайтными кодировками.

А где примеры софта про который утверждается, что он

не будет работать нормально. Я пробовал, баги лезут

в случае однобайтных кодировок?

Я тебя испугаю: у меня и веб-сервисы в локали КОИ8. Только никто не парится, потому что там вообще нет кириллицы (за ненадобностью).

Если нужна локализация, то есть gettext, который я активно использую. И получаю двухЪязычные утилиты. И все работает как в нормальной, так и в хрюникодовой локали!!!

нету в profile.env, там

export LANG='en_US.utf8'
export LC_COLLATE='C

Кем ты работаешь?

Это мой десктоп. Сообщения о кривой локали появляются в терминале когда от рута что-нибудь делаю с emerge, например систему обновляю, или при синхронизации с репами, или при depclean...

Какая разница?

Просто интересно, откуда столько свободного времени?

Это руби и питон3 то однобайтные? Вот с ｃｏｒｅｕｔｉｌｓ и будешь сидеть, у тебя из из однобайтного софта в списке только ｍｕｔｔ, только мне интересно как он работает с емейлами в юникоде без юникода. А компилятор и с триглифами будет работать — тяжкое наследие каменного века.

С однобайтными кодировками всё работает само без свободного времени.

Кстати весело ещё может случится когда подключаешь файловую систему с юникодом, а утилиты и ядро у тебя не умеют. Ноо... Это тебе надо древние версии софта использовать ещё наверно, там где о юникоде не слышали. Ой сколько багов было пока этот юникод внедряли.

Это руби и питон3 то однобайтные?

Поддержка есть.

из однобайтного софта

Я не говорил, что это чисто однобайтный софт. Я утверждаю, что весь основной софт умеет работать как с юникодом так и с однобайтными кодировками.

Поэтому примеры софта, который, как утверждается, с однобайтными кодировками работает плохо, в студию. Сам я из такого могу привести, например, telegram-cli, который авторы изначально научили только UTF-8.

Наоборот веселее. В однобайтных кодировках валидны любые последовательности байт. Поэтому хоть с неправильными именами, но с локалью KOI8-R видно всё. А вот когда наоборот парсер юникода ломается на «невалидных последовательностях байтов». Часть таких файлов/директорий может быть сложно переименовать или удалить, а часть могут и не отображаться вовсе. Так что, локаль KOI8-R надёжнее.

Ага, вот возьми-ка, да запихни либо в /etc/profile.d установку правильной локали, либо руту в ~/.bash_profile или ~/.bashrc. Потому что он у тебя без локали сидит, и какое-то ХЗчто эту татарскую локаль радостно выставляет.

Хотя, откуда у тебя вообще татарская кодировка берется, для меня загадка.

работает с емейлами в юникоде

А что, можно хрюникодовое мыло делать? Фигасе... Я думал, только ASCII туда допустим, да и то, не все символы!

Посмотри таблицу символов и управляющих последовательностей на досуге.

только мегабакс мог спалить кой8дика

чеза DE?

руки бы отрывать за такое:

~/.config/plasma-locale-settings.sh

Это уже другой вопрос. Суть в том, что символьный парсер только у юникода. Нет парсера - нечему ломаться. Есть парсер - он то и дело ломается.

Давай без юникода, создай файл с \n в имени и посмотри как много софта его корректно обработает.

В Gentoo ещё языки в LINGUAS задаются. Посмотри, может там есть tt.

Ну какой идиот будет '\n', пробел или не-ASCII символы в имя файла загонять? Разве что полный даун...

Всё нормально, ls, mv, rm, cat, vim, sed,... и т.д. работают с таким файлом нормально. Проблема возникла разве что у GNU ed'а, который просто не видит такого файла в ФС. Мой форк ed'а 1987-го года с таким файлом прекрасно работает.

Вендузятник что ли? Может ещё и файлы типа CON запретишь? Это валидная последовательность на нормальных системах, более того, это однобайтный символ.

Давай начнём издалека. Ты уверен, что ты такой файл создал?

Это проверка надёжности однобайтных кодировок же. При локали UTF-8 парсеры этого юникода же то и дело ломаются. А в однобайтных кодировках любая последовательность байтов - валидный текст. Поэтому и юникодные имена при однобайтной локали не страшны, но не наоборот.

Парсеры юникода никогда не ломаются. Совсем, в принципе, это фича (да, я знаю как вызвать бсод в венде 1 последовательностью юникода из ～3 байт, но это легаси и проблемы индусов майкрософта). Может у тебя софт говно? Фишка в том, что нормальный юникод превратится в управляющие последовательности в однобайтных кодировках.