Файловая система: Регистро-зависимая vs Регистро-независимая

Причем кириллических локалей больше одной.

Живых одна: ru_RU.utf8.

Там был французский и его уже давно забыли.

Французский тоже использует латиницу. Нзвать файл otpusk.doc это не помешает.

Есть люди, которые пишут документы в Ворде

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

английский знать вообще не надо.

Работая за компьютером английский знать НАДО. Также как врачу надо знать латынь. Хотя уровень чтения в оригинале Шекспира или римских философов и не требуется.

Для этого мне нужно найти комп без русской локали. А таковых у меня под рукой нет и не было. Но если вдруг появится — обязательно попробую.

Французский тоже использует латиницу. Нзвать файл otpusk.doc это не помешает.

Или euxtpousque.doc. Что тоже понятно, но поменьше.

на моём компе есть те локали, которые мне нужны. А чужими и так и так пользоваться неудобно

Понятно что чужими пользоваться неудобно. И не только компами. Но периодически приходится. Было бы не надо - не носили бы с собой файлы на флешках. Таскать с собой свой ноутбук далеко не всегда возможно.

Да фигня-вопрос. Можно написать скрипт на перле для расчёта расстояния Левенштейна с учётом французских приколов, затем использовать его через find -exec, потом отсортировать результаты и другим скриптом на awk’е предоставить агрегацию наиболее вероятных файлов. Гораздо ж удобнее, нежели find path -iname отпуск.doc. Всё для вашего комфорта!

А главное, после ста лет можно смело сказать, что изначальная идея провалилась. Широкие народные массы как песали бесграматна, так и продолжают.

Но это не значит что есть смысл принудительно сохранять в языке искусственные сложности.

The European Commission has just announced an agreement whereby English will be the official language of the EU

Международная стандартизация в действии. А уж какие именно упрощения допускать - вопрос дискуссионный. Что-то приживается, что-то нет. Рассудить может только время. Например я учился русскому языку в школе на рубеже 70-80х. И вижу что современный русский довольно заметно отличается, особенно у молодых людей. Хотя всего-то четыре десятка лет прошло как я школу закончил. А если починать книги и газеты 30х годов прошлого века то различия еще более заметны. Хотя это уже «послереформенный» русский. Даже произношение дикторов в старой советской кинохронике отличается.

А некоторые страны вообще на латиницу переходят, например Казахстан. Потенциальная выгода настолько велика что их не смутила даже затратность самого процесса перехода.

А некоторые не переходят, например Китай. Хотя казалось бы, насколько всё упростится – и устаканенной общепринятой системе транслитерации на латиницу (пиньинь) уже больше полувека. Тем не менее не переходят.

И тут появляется подозрение, что эта самая выгода не является чем-то объективным как 2*2, а напрямую зависит от приоритетов развития общества в конкретной стране. Но дальнейшее развитие этой мысли невозможно без ухода в нацпол, поэтому здесь я останавливаюсь.

искусственные сложности.

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

А если починать книги и газеты 30х годов прошлого века

Лучше б Пушкина читали. Или Гончарова.

Угу. У меня, кстати, прогрузилось, но где-то через минуту.

Поэтому файлы называются буквами, которые есть у людей на клавиатурах.

Вот именно - есть на клавиатурах. А клавиатуры сами по себе национально-специфичны. Как и типчные комплекты установленных шрифтов в разных странах отличаются, а шрифтов, содержащих все полторы сотни тысяч юникодных глифов по-моему вообще ни у кого на компе нет. Отсюда следует, что для международного обмена данными так или иначе придется выбрать некое стандартное подмножество букв. Вопрос лишь в его размерах.

Страдания пользователей мейнфреймов и оболочек, прибитых гвоздями к ADM-3 нормальных людей задевать не должны.

С этой точки зрения и страдания людей с ограниченными физическими возможностями тоже «нормальных людей» задевать не должны. Не надо строить пандусы и прочие элементы комфортной для таких людей среды. И помочь такому человеку преодолеть сложное для него препятствие - тоже не надо. Но лично я придерживаюсь других взглядов и в своей деятельности изначально учитываю потребности таких людей если для меня это не составляет никакого труда. Файл названный на латинице и без пробелов - один из таких случаев. Мне абсолютно не трудно, а кому-то сэкономлю время и усилия.

Причем бывает даже и самому себе если вдруг потребуется воспользоваться каким-нибудь софтом у которого проблемы с именами файлов, содержащими пробелы,спецсимволы, национальные буквы. А тако бывает если программу писал кто-то для себя но потом она разошлась сначала по знакомым, потом по сети.

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

Жалко, что ЛОР не позволяет картинки в сообщения вставлять. Конечно, можно быстро превратить форум в клоунаду, но здесь как раз тот самый случай, где функциональность не помешала бы.

«юникод» означает «универсальный», т.е. повсеместно используемый

Там «универсальный» - в смысле теоретической возможности отображать любые языки,а не в смысле обязательного использования везде. Наиболее наглядный пример - всякие микроконтроллерные девайсы где в абсолютном большинстве случаев байт==символ на знакосинтезирующем индикаторе. Потому что так в самом индикаторе прошито в железе.

при наличии какового, любые другие кодировки более не нужны.

Нужны. Именно поэтому их поддержка сохраняется и в линуксе и в виндах.

Вот мне радости больше нет, чтоб данные файла в одной кодировке, а методанные — в другой.

Имя файла - на латинице. Метаданные - в какой хотите кодировке. Хотите в юникоде - пусть будут в юникоде. Это как в математике - формула из латинских (и иногда греческих) букв, а пояснения к ней на любом языке. Кстати, внедрять русские буквы в формулы пытались, видел такой советский учебник экономики. Не взлетело. Кстати интересно - в конце 80х на машинах Искра-1030 был русифицированный клон ДОС, допускавший русские имена файлов. Только его все на обычный «англоязычный» DOS сразу меняли и называли файлы латинскими буквами.

надо

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

Создавайте отчёты об ошибках, а лучше шлите исправления.

Кому слать если автор лет эдак 10-20 не занимается программой? Как сделал ее или в порядке хобби или в качестве например курсовика/диплома, выложил куда-нибудь, так и оставил. И даже первоначальное место выкладывания могло уже исчезнуть если это была домашняя страничка на каком-нибудь бесплатном хостинге. Также напомню, что большинство «самодеятельного» софта отдается AS IS, то есть вообще без каких-либо гарантий и обещаний, в том числе какой-либо поддержки.

Отдельно отмечу что я,как и большинство россиян, не настолько хорошо владею иностранным языком чтобы вести на нем переписку с автором и объяснять ему где там у него ошибка. Я как та собака - прочитать могу не сложный текст, а вот написать грамотно - увы:(

Сделаем этот мир лучше! Иначе так в болоте говнокода и потонем.

Я согласен с вашими устремлениями и даже иногда мне удавалось что-то сделать в этом направлении. Но это были именно единичные случаи, и уж точно не относящиеся к поддержке национальных алфавитов в софте. Мне проще использовать латиницу.

значит китайские иероглифы не являются для них проблемой.

Внутри файла - да. Потому что их там интересуют принципиальные схемы. Да и гугл относительно терпимо переводит файлы с китайского на английский. А вот иероглифы в имени файлов - неудобны, поэтому такие файлы сразу переименовываются в латиницу, прямо в процессе save as в браузере при скачивании.

Но вы же пихаете.

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

Лучшей альтернативы тоже нет.

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

На ВАШЕМ компе. А так-то их существенно больше одной. К примеру у меня есть справочники и документация по старым советским деталям и аппаратуре - там куча нарисованного псевдографикой в 866 кодировке потому что созданы они были еще под ДОС. Когда мне нужно поработать с этими файлами - я запускаю софт с 866 локалью. Благо в линуксе локаль является атрибутом именно процесса, а не юзера. Если мне надо поредактировать исходник для микроконтроллерной железки у которой на индикаторе «байт»==«символ» то я тоже использую однобайтовую локаль. Чтобы не мучиться с строковыми литералами. Тем более что в любительских проектах для МК еще и комментарии обычно в виндовой кодировке 1251. Я просто использую предоставляемые мне системой возможности работы с разными локалями. Если вам эти возможности не нужны и вы ими не пользуетесь - ничего не имею против. Я тоже много чем не пользуюсь.

Для этого мне нужно найти комп без русской локали.

Я думаю будет достаточно установить через переменные окружения виндовую локаль (CP1251)- линукс ее полностью поддерживает. Причем ничего в конфигах менять не надо, просто запустить xterm с этими переменными окружения и (возможно) выбрать в нем соответствующий шрифт.

Или euxtpousque.doc. Что тоже понятно, но поменьше.

Даже не столь важно насколько оно понятно. Хотя изучавшему несколько лет французкий как минимум известны французские правила чтения. Важно то, что это имя файла не создаст проблем ни на одном компе ни в одной программе. Чего нельзя сказать о имени с русскими буквами. Тем более что в отпуск сейчас ездят не только по России.

А ещё можно член себе нарочно дверью прищемить и рассказывать всем про неправильные двери.

А некоторые не переходят, например Китай.

У них на то действительно причины из области нацпола, их внутреннего. Китай внутри слишком неоднороден и иероглифы это то что их объединяет(одно из). Потому что пишутся они везде одинаково, а вот читаются в разных диалектах языка настолько по-разному что китайцы из разных мест с трудом понимают друг друга.

устаканенной общепринятой системе транслитерации на латиницу (пиньинь) уже больше полувека.

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

Туземец, выросший на пиджин инглиш

Тем не менее необходимость пиджин инглиш понимали еще тогда когда он появился. Да и большинство носителей нормального английского с трудом способны читать например Шекспира в оригинале. И уж точно говорят и пишут не так как он. У нас с прочтением Пушкина всё куда лучше.

здесь как раз тот самый случай, где функциональность не помешала бы.

Или хотябы договориться и выбрать какой-то удобный всем файлообменник который у всех открывается и не требует регистрации при помещении файлов. У меня например хорошо работает https://catbox.moe

А так: euxtpousquè.doc?

Шучу, шучу. Любую здравую мысль можно извратить.

Только не говорите что в линуксе плохо с поиском. Но к сожалению не так много людей хорошо умеют пользоваться регэкспами.

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

можно привести примеры?

Читал такое правда не про дверь, а про турникеты какие-то, вроде метрошные не помню уже где. Мужчина получил удар этим турникетом по прчиндалам, подал в суд и выиграл. Читал это давно, лет 20 назад, подробностей не помню.

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

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

Можно. Известно, что винды, линукс и мак имеют разное мнение о том как кодировать в именах файлов «составные» символы («буквы с крышками»). Не помню точно кто из них как, но одни используют глиф «буква с крышкой», а другие «буква отдельно, крышка отдельно» - два совмещенных глифа.

В юникоде есть такое действие как «нормализация» (https://habr.com/ru/companies/ruvds/articles/445274/) и оно неоднозначно. Возможны варианты. То есть сделав монстрообразный юникод, его разработчики пришли всё к тому же - к необходимости хоть как-то попытаться обеспечить однозначность байтового представления внешне идентичных строк. Получилось весьма не очень.

Базовые компоненты системы должны быть устроены максимально просто и предсказуемо.

Это принцип, оторванный от реальности. Базовые компоненты системы должны служить клиентским компонентам, иначе их простота и предсказуемость будут нужны только для образовательных целей.

тривиально реализуется на програмном урове над файловой системой

На практике уровень файловой системы настолько влиятельный, что если следовать историческому аргументу (с которым мне сложно спорить), то Windows до сих пор не может включить регистрозависимость по умолчанию.

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

Вот, более 20 лет сижу на линуксе и тут внезапно узнаю, что я оказывается всё это время ужасно страдал и мучился.

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

Отдельно отмечу что я,как и большинство россиян, не настолько хорошо владею иностранным языком

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

Почему-то все ваши варианты сводятся к расхищениям кладбищ и разграблением музеев.

Необходимость бывает разная. Кому-то необходимо понимать приказы белых хозяев. Кому-то — самому стать хозяином.

Поддержка юникода сейчас является нормой, а самое простое с ней - это регистрозависимые ФС.

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

Однако, неспособность решить практические задачи - это объективный недостаток, который нужно решать, а не искать оправдания.

Костыли и привычки из винды являются именно костылями и привычками винды.

s/винды/линукса/g

Пренебрежительный взгляд в глаза оппонента не решит конфликт.

Надо ещё учитывать, что большинство программ будут повторять системное поведение, потому что именно этого от них ждёт пользователь (например, поиск в /bin/less регистрозависимый, хотя казалось бы).

Не могу воспроизвести:

% echo $LANG
en_US.UTF-8

% find . -type f -iname '*отпуск*'
./Отпуск за свой счёт.doc
./Заявление от отпуск (шаблон).doc

% find . -type f |grep -i отпуск
./Отпуск за свой счёт.doc
./Заявление от отпуск (шаблон).doc

% find --version |sed 1q
find (GNU findutils) 4.10.0-dirty

% grep --version |sed 1q
grep (GNU grep) 3.12-modified

На маке тоже работает:

% echo $LC_CTYPE
UTF-8

% grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD

(У /usr/bin/find нет аналогичного флага.)

И именно для того чтобы ее людям не создавать - надо называть файлы латиницей

Допустим, как мне именовать файлик «Общий анализ крови.pdf»? «Obshii analiz krovi» или «Complete Blood Count»? С транслитом тоже беда - й,я,ж и прочие можно написать по-разному, соотвественно при поиске файла опять придется учитывать разные варианты.

И почему транслит, и тем более правильный перевод, будет удобней, особенно для того, кто не знает английский?

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

без проблем

> ls -l
total 0
-rw-rw-r-- 1 andrey andrey 0 Apr  5 21:04 абвгд
-rw-rw-r-- 1 andrey andrey 0 Apr  5 21:03 тест
-rw-rw-r-- 1 andrey andrey 0 Apr  5 21:03 Тест
> find . -iname "тест"
./тест
./Тест
> locale -a
C
C.utf8
en_US.utf8
POSIX
> cat /etc/debian_version
13.4

Враньё, пробелы в досе использовать можно

У меня не получилось (альтернативная ссылка).

Очередной раз повторю, смайлы тут ни при чём! Никаким боком, вообще

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

Проблема состоит именно в том, что рисователи юникода забили

причем тут рисователи юникода? Это «A󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑A» прекрасно ищется браузером на странице, как по «AA» так и по «aa», а вот весь остальной утиль (find, grep, less и пр.) уже не справляется, забавно что spotlight тоже не справляется.

mcedit например ей уже следует

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

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

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

Я с тобой соглашусь, что если мы говорим о документах, которые изначально предполагают международное использование, то логично сразу именовать на английском (не транслитом!), да и сам бы документ переводить. Но таких документов будет сильно меньше, чем тех, что внутри себя

Это просто обычная вежливость - не создавать неудобств другим людям если этого можно легко избежать.

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

Вроде в mc проблем нет:

⛅️.txt        ----   0     1/2      0/43 0087 0x057 UTF-8
      1 Weather: ⛅ ️3.8°C 741mmHg WNW 8.4kmh
      2 

Это command.com кавычки парсить не умеет видимо. Из nc создастся, ну или своей прогой которая int 21h вызовет для создания файла. Или может быть даже какой-нить дос утилитой (в edit есть «сохранить как»?)

Допустим, как мне именовать файлик «Общий анализ крови.pdf»? «Obshii analiz krovi» или «Complete Blood Count»?

Например так: ~/medicine/analizi/genblood/20260405.pdf

эта зараза пошла от них. Изначально-то Variation Selectors для благих целей, чтобы поддержать CJK, а потом началось:

Ты сам себе противоречишь, не находишь? Началось, значит, с CJK, а не со смайлов.

Зачем это в именах файлов поддерживать только…

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

причем тут рисователи юникода?

При том что там 50 букв а рисователь нарисовал всего две - это вводит юзера в заблуждение. А в поиск костыль прицепили чтобы криво нейтрализовать проблему. В grep костыля нет, юзер путается из-за неадекватного рендера терминал-эмулятора.

нет не следует - он просто обсирается: у двух символов длина в байтах довольно запредельная получается (194), он пытается обрезать чтобы в шапку вписать хоть что-то, но на выходе получается фигня, ровно то же самое наблюдается и для кириллицы

Я не понял что ты хотел написать, о какой шапке речь итд. Возможно у тебя какой-то другой mcedit. Мой mcedit рисует (ссылка) букву «A», затем 48 (как и положено) пустых клеток (это уже не совсем хорошо, лучше бы квадратики рисовал), затем ещё одну букву «A». Если наводить курсор на эти пустые клетки - правильно показывает их коды: 0xE015F 0xE0158 итд.

если отвлечься от разбивки по каталогам, то прям какая-то мешанина получается, что-то транслитом, что-то перевод, причем нестандартный. Что бы всем неудобно было?)

З.Ы. понятное дело вопрос как раскладывать очень спорный и у каждого свое мнение, но в данном примере лично для себя решил что проще класть все документы за год в один каталог, без разбивки по типам. Как-то у меня чаще получалось, что важен набор результатов в определенный период, а не просто разбивка по типу

Через edit тоже не получилось. А вот nc – действительно, создал файл.

Это принцип, оторванный от реальности

Этот принцип и есть наша линуксовая реальность.

Базовые компоненты системы должны служить клиентским компонентам

И для этого они должны быть простыми и предсказуемыми.

если следовать историческому аргументу (с которым мне сложно спорить), то Windows до сих пор не может включить регистрозависимость по умолчанию.

Тут только следует порадоваться, что нам не нужно притворяться DOS’ом на максималках. А проблемы винды и макоси — пусть остаются с виндой и макосью.

Уровень над базовой системой - это либо фрагментация пользователей,

Это совершенно нормально. Я вообще не понимаю тяги заставить всех строем ходить.

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

Мой позитивный опыт основан на том, что я хорошо делаю, а плохо не делаю. Возможно менее продвинутым пользователям стоит брать пример с более продвинутых. Тогда и у них тоже всё хорошо будет.

Без понятия, что там с поиском в разных DE. По сути нужна лишь галка в поиске «с учётом или без учёта регистра». Не в консоли же секретарша искать будет.

Например так: ~/medicine/analizi/genblood/20260405.pdf

Это чтоб ни поиск по транслиту, ни по-английски не сработал. Страдать так страдать!

Важно то, что это имя файла не создаст проблем ни на одном компе ни в одной программе. Чего нельзя сказать о имени с русскими буквами.

Программы, у которых проблемы с юникодом или пробелами в именах файлов отравляются в /dev/null. Не надо оправдывать говнокод.