LINUX.ORG.RU

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

 , ,


2

1

При работе в терминале постоянно выскакивает ошибка

cannot change locale (tt_RU.UTF-8): No such file or directory

Откуда взялась эта кривая локаль? И как её убрать?

# cat /etc/locale.gen
# /etc/locale.gen: list all of the locales you want to have on your system.

en_US ISO-8859-1
en_US.UTF-8 UTF-8
#ru_RU ISO-8859-1
#ru_RU.UTF-8 UTF-8

locale-gen
 * Generating 2 locales (this might take a while) with 4 jobs
 *  (1/2) Generating en_US.ISO-8859-1 ...                                                                     [ ok ]
 *  (2/2) Generating en_US.UTF-8 ...                                                                          [ ok ]
 * Generation complete
 * Adding locales to archive ...
# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=tt_RU.UTF-8
LC_CTYPE="tt_RU.UTF-8"
LC_NUMERIC="tt_RU.UTF-8"
LC_TIME=tt_RU.UTF-8
LC_COLLATE=C
LC_MONETARY="tt_RU.UTF-8"
LC_MESSAGES="tt_RU.UTF-8"
LC_PAPER="tt_RU.UTF-8"
LC_NAME="tt_RU.UTF-8"
LC_ADDRESS="tt_RU.UTF-8"
LC_TELEPHONE="tt_RU.UTF-8"
LC_MEASUREMENT="tt_RU.UTF-8"
LC_IDENTIFICATION="tt_RU.UTF-8"
LC_ALL=


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

anonymous ()
Ответ на: комментарий от Samsky

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

Chord ()
Ответ на: комментарий от Samsky

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

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

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

Chord ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от Chord

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

anonymous ()
Ответ на: комментарий от saahriktu

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Chord ()
Ответ на: комментарий от saahriktu

Это руби и питон3 то однобайтные? Вот с coreutils и будешь сидеть, у тебя из из однобайтного софта в списке только mutt, только мне интересно как он работает с емейлами в юникоде без юникода. А компилятор и с триглифами будет работать — тяжкое наследие каменного века.

anonymous ()
Ответ на: комментарий от saahriktu

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

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

saahriktu ★★★★★ ()
Ответ на: комментарий от Chord

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

saahriktu ★★★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

saahriktu ★★★★★ ()
Ответ на: комментарий от saahriktu

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

anonymous ()