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

И пробелы еще были недопустимы. Ну, вот при этом как раз и есть помянутая мною выше 8.3, которая как раз и следовала ограничениям на имя файла (и, как следстве, каталога, ведь каталог – тоже файл). Из той же эпохи перехода от DOS к win95 была и рекомендация не использовать русские буквы в именах файлов.

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

Археология и труположество. Я говорю об актуальных файловых системах.

С современными ФС тоже есть проблемки. Так всегда, с появлением какой-то новой технологии появляются и сопутствующие ей проблемы. Но в целом, лично у меня файловая система работает штатно и позволяет давать файлам осмысленные имена. Да, обработка Юникода усложнила файловые системы и сопутствующие им программы, но это шаг вперëд, а не назад.

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

Враньё, пробелы в досе использовать можно. Причём, есть одна тонкость: если ты в досе создашь файл «A B» - он так и будет файлом с именем из трёх символов, а если ты его создашь через оффтопный драйвер фата - то у него будет длинное имя «A B» и короткое «AB~1». Почему-то писатели оффтопного фат-драйвера тоже думали что в досе нельзя пробелы, видимо это распространённое заблуждение.

Вот у меня есть два файла:

Заявление от отпуск (шаблон).doc
Отпуск за свой счёт.doc

Как мне найти оба этих файла без приседаний?

Приседания не нужны. Нужен вис на перекладине. И man find прочитать, конечно же. Но сначала к турнику.

И`man find`прочитать

Без приседаний

Могу только отметить, что ваше нежелание читать документацию, потребность игнорировать регистр букв и индийский ник находятся в удивительной гармонии между собой.

Я делаю так:

find . -type f |grep -i отпуск

Иногда так:

find . -type f |grep тпуск

Esc, '?', '*отпуск*', снимаешь галочку с «учёт регистра», enter

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

Правильный ответ: find path -iname pattern. Ваш тоже работает, конечно, но идея сначала нагенерировать мусорные данные, потом героически их отсеивать в поисках нужного — странная. Такой работы мне и на работе хватает.

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

идея сначала нагенерировать мусорные данные, потом героически их отсеивать в поисках нужного — странная

grep не устанет. А идея такова 1:

grep — общий инструмент поиска, find — специальный API. Выбирая grep мы можем перенести имеющиеся скиллы в новую задачу, а выбирая find мы можем сделать что-то особенное, трудновыразимое другими средствами, но потеряем в лёгкости восприятия (например, %TFT%TT не так сильно распространён как ls -lt).

Я большой фанат «переноса имеющихся скиллов в новую задачу». Недавно узнал, что есть даже термин, обозначающий это — analogical transfer.

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

да как без приседаний! так, с турником и приседать!!! :о)

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

Find — это базовая, одна из наиболее часто используемых линуксовых программ, если уж сидишь, смотришь в чорную консоль, то её нужно знать.

Мне не особо пригодилось. Единственное, нет стандартного или очевидного аналога find . -type f. А так да, знать приходится, хотя бы чтобы понимать что написали другие люди.

Жесть, конечно. Регистронезависимость нужна была просто для удобства поиска файлов. Секретаршу, ищущую регэкспами, хрен найдёшь. Такая, разве что у Sun-ch’а, была, и то не точно.

Есть языки (точнее алфавиты), где второго регистра нет или почти нет.

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

в иврите (там только у некоторых букв есть «конечный» вариант, который пишется в конце слова, но у большинства нет)

Здесь бы о сигме вспомнить закрытой и открытой. И о длинной s, которую сейчас можно разглядеть разве что в ß, в знаке интеграла и фонетических транскрипциях.

и арабском

Четыре позиционных варианта: начальный, срединный, конечный, изолированный.

Но в этих наших линуксах можно включить регистронезависимость, а в офтопе – выключить. Простому обывателю это обычно не нужно, как и системные часы в UTC. Но вот что винда чрезмерно усложнена – это да.

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

Это Петру I спасибо надо сказать, который царской рукой нарисовал буковки «как у них» и при этом как запомнил и понял, и велел всем так же. В уставе и полууставе отличались сильнее. По этой же причине от сама строчка печатная выглядит странно, если на неё посмотреть как бы замутнённым взглядом — не читая, но видя рисунок. В латинице сбалансировано получается, сколько выносных элементов вверх и вниз у маленьких букв, а в кириллице так получилось, что вверх вообще только у буквы одной буквы б торчит, а вниз — как в латинице.

По ссылке не описано ни одной «проблемы со смайликами». Единственное что там описано - это проблема идиотизма юникода в плане рендеринга. С конкретно именами файлов это не связано.

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

Это Петру I спасибо надо сказать

если бы в начале становления IT в Союзе, всем этим бы заправляли такие же сталкеристы как и @CrX, то мы бы имели примерно тоже же самое что и в POSIX: файлы (и все остальное) шло бы в перемешку с англоязычными названиями, и для конечных пользователей это было бы сущим адом, очень хорошо, что в те времена люди имели лучшее в Мире Советское образование и отстояли национальный алфавит (в отличии от бомжей из Западной Европы)

Графическое изображение обсуждаемой темы

Шутки шутками, но я считаю что если имеют разные значения, то они должны иметь разное значение

Ну наконец-то! вы стали серьёзным.

А никто в файловые системы это и не затаскивал. Повторюсь: имя файла - это блоб, в котором запрещены байты 0 и '\'. То, что его некоторые утилиты или терминалы выводят на экран, парся как utf-8 кодировку текста - проблема интерфейса этих утилит, а не файловой системы. Могли бы, например, hexdump-ом имена выводить. Но я, повторюсь, за такой подход: codepoint=знакоместо. Он тоже устраняет все проблемы, но при этом относительно совместим графически с имеющимися юникодными текстами, которых наплодилось очень много и исправить на хорошую кодировку не представляется возможным.

Ссылка неоткр в РФ

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

а в кириллице так получилось, что вверх вообще только у буквы одной буквы б торчит, а вниз — как в латинице.

Вы букву в потеряли. И валите с больной головы на здоровую. Государь император не виноват, что дурные большевики конечный ъ, ѣ и i отменили.

А, вот, что кириллическая каллиграфия не получила своего продолжения — и вправду жаль. Довольно интересно могло получиться. Впрочем, потомки всегда могут продолжить. Это культура, она вне времени.

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

ну не знаю что не ясно:

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

@CrX - сталкер как он есть, буквально в течение минуты какие-то реакции лепит, при этом уровень знаний откровенно нижу плинтуса (Петра Первого приплел к юникоду зачем-то)

Тебе не надоело нести всё более и более сумасшедший бред?

Вы букву в потеряли.

Так у неё в обычном печатном шрифте, не курсивном вариенте нет выносного элемента. В болгарице только есть. Занятная, кстати, штука, хотя для нас, привыкших к обычной кириллице смотрится как-то странно.

Государь император не виноват, что дурные большевики конечный ъ, ѣ и i отменили.

Это справедливое замечание, да.

А никто в файловые системы это и не затаскивал. Повторюсь: имя файла - это блоб, в котором запрещены байты 0 и ’'

как раз все беды именно таким образом и затащили, ровно как и в Ответ на: комментарий от kaldeon я и писал: ну да, какие-то проблемы существуют - пусть этим кто-то другой занимается. Если абсолютно весь прикладной софт (и скорее всего не особо-то и весь, и на lib.c.so.6 какая-то ответственность возлагается) должен в итоге расхлебывать все это дерьмо, разве это не означает, что в консерватории изначально что-то пошло нет так?

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

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

Ваше профессиональное мнение очень важно для нас.

Так у неё в обычном печатном шрифте, не курсивном вариенте нет выносного элемента.

Согласен.

P.S. Предыдущее замечание лучше проиллюстрировать примером.

Если ты про юникодные проблемы, то совсем не весь.

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

То что в терминале нужно подсвечивать дерьмо как дерьмо особых вопросов не вызывает, вопрос лишь в том, кто это допустил и почему это нужно сопровождать. Условно: хорошо, приняли за догму, что в ядре названия файлов - это байты, кто после этого должен пользователей защищать от ошибок? libc? - там ровно такие же черти как и в ядре, прикладное ПО? - я 10 лет назад нетленку написал, а сейчас в ней «внезапно» дыры нашли - я виноват в том, что этого 10 лет назад не предвидел?

я вполне спокойно могу себе позволить практически в любом месте рисовать смайлы или еще что-то

И что? Это обычные символы, никаких проблем они сами по себе не создают. Чем рисунок смайла технически отличается от рисунка буквы А? Или от псевдографики которая в досе вовсю использовалась.

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

Допустили некомпетентные разработчики. Так бывает.

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

Никаких ошибок это спровоцировать не может.

И что? Это обычные символы, никаких проблем они сами по себе не создают

если я посредством пары-тройки смайлов начну через LOR сливать государственные тайны, то кому изначально прилетит? Мне или Макскому? Здесь даже если Макс ни в чем в итоге и не виноват, то пребывание СИЗО даже на пару-тройку дней врядли получится сравнить с санаторием-профилакторием.

Здравых идей, кроме как резать все это дерьмо на входе, не существует.

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

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

Но исторически сложилось как сложилось. То же и с регистрозависимостью.

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

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

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

A󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑A

Две латинские буквы A, между которыми какой-то невидимый юникодный мусор. Но если открыть файл с этими буквами в mcedit - мусор станет уже заметным, правда вместо него будут не квадратики как обычно, а пробелы.

Проблема состоит именно в том, что рисователи юникода забили на элементарное правило: нарисовал знак (в контексте юникода это число в диапазоне 0..10FFFF т.е. 20.1 бит информации и никак не больше) - сдвинь курсор на единицу вправо. Правило исправляется так же элементарно - возвратом адекватной логики рисования (mcedit например ей уже следует). Повторю ещё раз - это проблема рисователей текста и только их, а не чья-то ещё.

Ещё вторая, чуть менее существенная: в юникоде много одинаково выглядящих символов с разными кодами, их сложно на вид друг от друга отличить (в обычных кодировках такое тоже имеется, но меньше - например латинская и кириллическая маленькая буква «а» почти везде выглядит одинаково). Поскольку проблема существовала и без юникода, думаю не стоит тут на ней заострять внимание. Разве что избежать рисования чего-то кроме 0x20 и возможно ещё одного символа (неразрывный пробел) пустой клеткой.

Что касается стеганографии, про которую ты пишешь, то для неё и так и так имеется море способов, никак не связанных с вышеупомянутыми особенностями.

Идентификаторы в коде тоже теперь можно называть по-русски во многих ЯП.

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

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

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

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

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

В общем, вся тема яйца выеденного не стоит.

Ничего хорошего в отходе от стандартных правил не вижу.

Это может быть полезно например при написании программы расчёта бухгалтерии и т.п. с использованием терминов из нормативных документов. Так в языке 1С делают.

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

«проблемы» если и наблюдаются, то исключительно у турков, которые меж тем черт его знает сколько времени сидят на MS Windows и проблем не испытывают. Здесь точно имеет смысл обращать на это внимание?

Любая последовательность байт, укладывающаяся в эти ограничения — допустимое имя файла.

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

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

Экзотическими символами в имени файла вы создадите проблемы не системе, а людям которые вашим файлом будут пользоваться. Представьте что вам пришлют несколько файлов с именами из иероглифов. Скорее всего вы даже не сможете их назвать вслух если вас спросят в каком из них находится нужная информация. Да и различать иероглифы особенно в малых размерах шрифта - довольно затруднительно для человека, не знающего китайский язык. Для не знающего русский почти такие же проблемы создась имя файла на кириллице. Обратите внимание что в цивилизованном мире всякие таблички и указатели дублируются латиницей если местный язык использует другую письменность. Даже у нас в РФ в крупных городах это стали делать. А некоторые страны вообще на латиницу переходят, например Казахстан. Потенциальная выгода настолько велика что их не смутила даже затратность самого процесса перехода.

«проблемы» если и наблюдаются, то исключительно у турков, которые меж тем черт его знает сколько времени сидят на MS Windows и проблем не испытывают.

А ещё есть языки, в которых изображение в верхнем/нижнем регистре зависит от положения буквы в слове. Даже у греческого, оказывается есть такой прикол, в теме приводили пример. И даже у западноевропейских что-то такое есть.

Проблем турки может и не испытывают (кстати, не знаю), но вот зачем это всё тащить в ФС? И ещё вопрос каких они проблем не испытывают, может просто забили на фактически неправильную работу?

Тогда получается, что говорим «регистронезависимая ФС», подразумеваем, что это только про чистую латиницу и ещё может несколько алфавитов и всё.

Не весь софт корректно поддерживает символы за пределами 32..126.

Более важно то, что не все люди корректно поддерживают символы за пределами 32..126. И если предполагается возможность отправки файла за пределы своего ближайшего окружения то есть смысл назвать его латиницей.

Потом я это поправил

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