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

Очень даже ломаются! Не раз мне встречались ошибки во время enconv! Приходилось указывать явно локали и вызывать iconv, тот без глюков просто не обрабатывает ошибочные символы...

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

Нда, извиняюсь, немного не так создал файл. Пересоздал уже правильно. Теперь и GNU ed с ним начал работать.

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

Может у тебя софт говно?

Нет, это особенность UTF-8. Софт может её игнорировать или нет. И часто ни разу не игнорирует.

нормальный юникод превратится в управляющие последовательности в однобайтных кодировках

И в крайнем случае такие файлы можно переименовать. В то время как при обратной ситуации юзер может даже и не узнать, что у него есть файлы с невалидными для UTF-8 именами.

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

Если ты создал правильно, то у тебя разве что тар с ним будет работать (при указании специального флага). Естественно для шелла придётся городить интересные конструкции. То, что ты видишь, скорее всего не настоящая последовательность.

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

Создавал из программы на Си используя

        snprintf(fname, 11, "test\ntezt\n");
        fname[11] = '\0';
        fptr = fopen(fname, "w");
При этом
puts(fname);
выдаёт
test
tezt

Из tcsh'а доступ к такому файлу осуществляется через
test?tezt?
При этом в выводе
strace cat test?tezt?
явно присутствует
openat(AT_FDCWD, "test\ntezt\n", O_RDONLY) = 3

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от anonymous

У меня для тебя плохие новости. В этой вселенной можно еще и хрюникодные домены и даже произвольные TLD. Так что если можешь, пересиди в параллельной.

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

Отлично, только надо было 0x0a присвоить. А теперь давай ты не знаешь где и когда тебе такой файл попадётся в процессе работы. Удачи в восстановлении утерянных данных.

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

И удачи заметить, что то-что пошло не так. Где и когда тоже.

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

Что значит «не знаю»? Если рабочие данные поступают по сети, то можно выбрать свои имена файлов для сохранения.

Зачем запускать процессы на произвольных наборах файлов без предварительно их рассматривания? Если человеку, например, по работе приносят флэшки с файлами с произвольными именами и он их обрабатывает не глядя, то у него с таким же успехом и юникодные парсеры могут что-нибудь запороть.

В сети же чаще всего юникодные имена файлов состоят просто из пробеллов, чисел и кириллицы. Без всяких управляющих символов в однобайтных кодировках.

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

Gentoo - это, конечно, хорошо.
Но тут все же нужен более дистронезависимый способ.

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

Ну там тебе архив с юникодом принесут. А во всех архивах сейчас юникод, кроме ублюдочного проклятого презираемого зипа, который может сохранять имена файлов в сраных однобайтных говнокодировках. То, что это малограмотные пользователи-мрази сохраняют однобайтные имена, это совершенно другая проблема. А тебе потом гадать, а что это это за кодировка и как же этот файл теперь скормить распаковщику. Так вот, перекодировал ты из юникода в свою Антонину, а там теперь совершенно интересные последовательности в именах файлов, которых никто не ждал. Это касается 99% софта.

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

Насчёт перекодировал я погорячился, большинство символов при перекодировани в Антонину будет заменено на знаки вопроса и прочее подобное. Я имел в виду прочитал ты это юникодное имя как Антонину (у тебя же софт не имеет представления о юникоде, правильно?)

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

unrar, кстати, умеет при распаковке конвертировать имена в однобайтные кодировки. Это самый простой вариант из всех возможных. Вот после распаковки .zip'ов может быть всякое. Однако, это уже другой вопрос.

Вопрос в другом. Вы предполагаете, что я запускаю процессы (которые по-вашему очень сильно зависят от спецсимволов в именах файлов) на произвольных именах файлах. Ведь только так можно как-то потерять свои данные. Только если, например, у скрипта, который был запущен, например, на /mnt/mpt7/dir1 слетит логика, и он начнёт портить данные в хомяке юзера.

Вот я и спрашиваю: зачем вообще запускать процессы на произвольных наборах файлов какие бы имена у них ни были?

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Пакетная обработка файлов, архивация — распаковка/упаковка (можно даже в гуе, не обязательно в консоли), бэкапы, проставление тегов/метаданных файлам или получение информации о/из них да и вообще любые операции с файлами. Всё это плохо кончится.

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

у тебя же софт не имеет представления о юникоде, правильно?

Основной софт знает про юникод, но при однобайтной локали теперь не юникод, а соответствующая однобайтная кодировка.

Вот специально создал почти самый страшный вариант имени файла, которое хорошо можно рассмотреть задействуя hexdump:

> ls | hexdump -C
00000000  21 20 1f 1e 1d 1c 1b 1a  19 18 17 16 15 14 13 12  |! ..............|
00000010  11 10 0f 0e 0d 0c 0b 0a  09 08 07 06 05 04 03 02  |................|
00000020  01 11 40 0a 74 65 73 74  0a 74 65 73 74 2e 63 0a  |..@.test.test.c.|
00000030  74 65 73 74 0a 74 65 7a  74 0a 0a                 |test.tezt..|
0000003b
Тут почти все управляющие символы кроме нулевого, который обработался как указатель конца строки. Просто «ls» его показывает как
! ????????????????????????????????@
А в mc он виден как
! ................................@
и доступен на чтение, переименование и прочее.

Без переименования к такому файлу из командной строки можно обращаться как к ??????????????????????????????????@

> cat ??????????????????????????????????@
1237>
При этом даже такие конструкции всё обрабатывают нормально (переместил чтобы в вывод не попали внутренности бинарника и исходника, которые теперь уже неактуальны):
> find . -type f -exec cat "{}" \;
1237>

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ещё раз спрашиваю: зачем обрабатывать пучками неизвестно что?

Если готовишь свои файлы к обработке, то готовишь свои файлы со своими именами. А чужие файлы - это чужие файлы. И если на них не смотреть перед обработкой, то и юникодные парсеры могут что-нибудь поломать.

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

Сколько у тебя файлов на компьютере? У меня ммм многие миллиарды, причём ещё больше в архивах разного рода. Ты будешь переименовывать каждый файл? Не забывай, что это нельзя автоматизировать. Причём сразу по ряду причин. Как ты будешь их обрабатывать, как управлять ими? Все они содержат ценные данны. Вот тебе эти данные понадобились, тебе нужно их получить для использования где-то ещё. Ты будешь десятки миллионов (по скромным оценкам маленьких задач неинтересных людей) открывать поочерёдно и контролировать каждый шаг? А если у тебя нет возможности знать, что в файле должно быть, а что получил ты и как оно отличается от требуемого результата?

Юникод не ломается, тебе покажут байты которые не смогли распознать именно как байты. Покажи мне пожалуйста валидный юникод, ломающий парсер. Желательно реальный. Стандартный утф8 давай, с утф16 проблемы у венды.

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

Это прекрасно конечно. Но любые скрипты работать не будут. Перебрать такие файлы ты просто так не сможешь. Хорошо. Как ты отличишь от 2 такого же файла, отличающегося каким-то из байт? Допустим, остальные файлы у тебя нормальные, а эти были юникодом, но у тебя 8-битная кодировка в системе. Выглядят очень похоже, визуально отличить никакой возможности. Как ты будешь с ними работать дальше?

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

Вариант «переименую нормально эти пару файлов» неправильный, во-первых ты не знаешь в какой кодировке они побывали и сколько преобразований прошли, во-вторых тебе не удастся это сколько-нибудь надёжно автоматизировать.

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

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

Конкретные имена файлов для юзера актуальны только для тех файлов, с которыми он работает вручную. Чтобы различать их. При этом во многих случаях не так уж и важно как перекодировались имена файлов. Можно посмотреть и дать свои имена. Или вообще оставить как есть.

А какие имена были у файлов, которые обрабатывали скрипты, потом уже ни разу не актуально.

В общем, имена файлов - это ни разу не проблема для однобайтных локалей. Проблема в 0x80-0xFF для юникодных парсеров.

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

Нащупал эту tt:

# emerge --info | grep tt_RU
LANG="tt_RU.UTF-8"

В make.conf этого нету, откуда ещё emerge --info зачитывает LANG при выполнении ?

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

Выглядят очень похоже

Как это «выглядят очень похоже»? Похоже на символ '?' выглядят только управляющие символы, которые ls отображает этим символом. При этом для того же mc это ни разу не проблема, и из него можно как переименовать файлы так и читать/модифицировать их. А на файлопомойках без mc делать особо нечего. Хотя и можно смотреть имена файлов через hexdump.

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

откуда ещё emerge --info зачитывает LANG при выполнении

Прогони через strace, посмотри открываемые файлы.

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

Вообще-то юзера не интересуют имена файлов (от слова совсем), юзера интересуют данные. Конечно, любой хочет данные, а не трахаться с именами файлов и глупыми проблемами кривого софта и OEM кодировок.

Но имена нужны для распознавания конкретного файла из тысяч-миллионов других похожих (или нет) и совершения над ним некоторых действий, совершенно не важно как они выглядят, что важно это то, что у оператора нет контроля над ними. Есть данные, и есть имя файла которое по какой-то причине разрушает софт при попытке с этим файлом работать. Из-за чего? На нормальной системе такого бы никогда не случилось.

Кроме того, зачастую имя файла само по себе данные, а утеря данных даже не по причине ошибок в софте, а из-за тараканов в голове оператора, непростительна. Поэтому у нормальных людей так горит, когда они получают какие-то крякозябры вместо имён файлов. А называть разнородные файлы 00001 00002 00003 00004 00005, без намёка на содержимое, не лучший подход. Допустим, оператор примерно помнит, где находится файл, и знает как он будет назван (хотя бы примерно). На его нахождение потребуются считанные мгновения. Если же имя файла не несёт никакой информации, придётся потратить многие дни на просмотр и анализ всех файлов и поиск необходимой информации (и это занятие вовсе не столь приятно, несмотря на кажущуюся тривиальность).

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

Ладно, я конечно заскриптую поиск по некоторым предполагаемым шаблонам имени, насколько это возможно или по содержимому/метаданным (далеко не лучший вариант, поиск по имени куда эффективней), но мне прилетит из-за приколов с \n в результате которых как миниумум не получишь результата, или же потеряешь данные. И это у меня юникод везде где можно. Что приходится переживать калекам на однобайтных кодировках и страшно подумать.

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

7z распаковывает с переименованием при помощи enconv, так что никаких проблем не будет, даже если архив создан дебилом!

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

Это всё какие-то редкие юзкейсы. В 99,99% случаев юзеру нужны данные внутри файлов. При этом с гораздо большей вероятностью это данные созданные им самим. Если же юзеру нужны данные не созданные им самим, то он скорее пойдёт за конкретным отдельным файлом и сам даст ему имя.

А всякие файлопомойки - это обычно так, поковыряться в условиях отсутствия конкретных задач и интернетов. Без всяких строгих требований.

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

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

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

Перебил этот tt_RU путем создания /root/.bashrc с таким контентом:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8

Спасибо тем, кто помогал.

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

А ты кто такой, вообще? Шёл бы ты отсюда, не мешай дискуссии.

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

Я тебя вижу, а ты меня видишь? Самый первый пост...

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

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

Французы гадят.

Grattez le Russe et vous verrez le Tatare.

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

В смысле «возвращаться»? Я и так здесь..

anonymous
()
1 января 2019 г.

tt_RU.UTF-8

Ну эта локаль появилась в plasma. Насколько видно из названия tt означает телетайпный вариант. Ну есть такой тэг в вебе ещё. Ну да ладно. Видимо там так решили, что и так сойдёт! Второе, локаль в системе и в KDE это не одно и тоже. По крайней мере сейчас. В системе как вызнаете стоит en_US.utf-8. Где локаль KDE я не знаю... Вы как вижу тоже её не нашли. Однако в системе есть др русскоязычне локали если запустить locale -a|grep -e RU, то выдаст(у меня Leap 15.0 OpenSuse): ce_RU cv_RU mhr_RU os_RU ru_RU ru_RU.cp1251 ru_RU.ibm866 ru_RU.iso88595 ru_RU.koi8r ru_RU.utf8 tt_RU tt_RU@iqtelif Как видите tt_RU тут есть. Но какая-то странная... Причём две! Однако в настройках плазмы в форматах при выборе региона есть 3, вон та cv_RU и какая-то bv_RU. Я так полагаю, это локали для кварталов русских мигрантов за границей. Судя по названию bv это Бавария а вот cv это Чувашия.Да, кстати locale-gen у меня нет. Не предусмотрено... В плазме да, приходится править локали, в отличие от 4-х кед.

Anatoly
()
27 мая 2020 г.

Топикстартер, ты разобрался, откуда браласть эта tt_RU.UTF-8? А то у меня сейчас берется непойми откуда.

hlebushek ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.