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

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

Эдик, прими таблетки.

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

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

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

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

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

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

        snprintf(fname, 11, "test\ntezt\n");
        fname[11] = '\0';
        fptr = fopen(fname, "w");

puts(fname);

test
tezt

test?tezt?

strace cat test?tezt?

openat(AT_FDCWD, "test\ntezt\n", O_RDONLY) = 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот специально создал почти самый страшный вариант имени файла, которое хорошо можно рассмотреть задействуя 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

! ????????????????????????????????@

! ................................@

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

> cat ??????????????????????????????????@
1237>

> find . -type f -exec cat "{}" \;
1237>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это вы калеки, хрюникодофилы недорезанные! Мочить вас в сортире!!!

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

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

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

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

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

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

Эдичка, возвращаться собираешься или нет?

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

Меня ты не видишь? Я у тебя в бане?

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

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

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

Grattez le Russe et vous verrez le Tatare.

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

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-х кед.

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