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

ПОЛНОСТЬЮ СОГЛАСЕН С ВАМИ. РАЗНЫЕ РЕГИСТРЫ НЕ НУЖНЫ. ДА И ЗНАКИ ПРЕПИНАНИЯ КОНЕЧНО ЕСЛИ ПОДУМАТЬ ЭТО ИЗЛИШЕСТВА ПРОБЕЛЫМЕЖДУСЛОВАМИТОЖЕПОЯВИЛИСЬДОВОЛЬНОПОЗДНОБЕЗНИХПИСАЛИИНОРМАЛЬНОБЫЛОЙЖМЛЧЧТГЛСНЗВКТЖНТКЖНЖН

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

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

Хорошо ещё не 3 регистра и не больше…

RrＲｒꝚꝛℜ𝔯𝕽𝖗𝓡𝓻𝕣ʳᵣ

Хорошо ещё не 3 регистра

Ты про:

1. Uppercase: DZ, DŽ, LJ, NJ
2. Titlecase: Dz, Dž, Lj, Nj
3. Lowercase: dz, dž, lj, nj

З.Ы.: попробуй выделить эти диграфы 😉

Если ограничить набор символов в именах файлов одним регистром то будет проще

Нет, не будет. Будет сложнее и ограниченнее.

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

И до этого были исправления правил. С учётом вариаций применения правил получить можно и так:

Maßstab -> MASZSTAB, MASS-STAB, MASSSTAB, MAẞSTAB

Здесь имеет место быть подмена понятий, а именно:

есть юникод, да, в нем имеют место быть некоторые неоднозначности, при этом:

• с одной стороны, в libc, да и в целом повсеместно, новые версии юникода тащат только в путь, и условно вчера в Германии месяц сентябрь сокращался как Sep, а сегодня, внезапно, оно стало Sept, и сразу же все парсеры текста отваливаются к херам, но тут же CLDR - это стандарт, его нужно поддерживать, все дела, а чего это поддержка стоит совершенно мало кого волнует
• а с другой стороны пытаемся объявить, что если какой-то пользователь раз в жизни столкнется с тем, что не получится файл создать, то всенепременно весь мир рухнет. Нет, не рухнет, и никто еще не умер от этого

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

Что за пакеты, например?

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

Масштаб таков:

a/
b/
c/
d/
g/
libg/
libm/
libp/
libr/
m/
o/
p/
q/
s/
t/
u/
x/

В каждом каталоге по два-три пакета. Что именно вело себя плохо, я сейчас уже не вспомню, но на машине для них завёл отдельный регистрозависимый foreign.dmg (да, расскажите мне, что линукс-разработку нужно вести исключительно на линуксе)

Звучит как сарказм и попытка довести идею до абсурда :)

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

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

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

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

На самом деле, когда в сообщении 1–2 предложения, это не так важно. Но когда это простыня текста на несколько абзацев (или и того хуже — без деления на абзацы), читать становится невозможно.

…Ну как невозможно. Это гипербола. Возможно технически. За деньги я бы читал, или если бы знал, что там содержится очень важная для меня информация. Но без особой мотивации — увольте.

Остаётся загадкой, зачем его надо было в юникод включать одним символом. Ди- он на то и «ди». Англичане вон не парятся насчёт sh или th.

Остаётся загадкой, зачем его надо было в юникод включать одним символом.

В Юникоде диграфу Dz присвоены коды U+01F1 DZ latin capital letter dz, U+01F2 Dz latin capital letter d with small letter z, U+01F3 dz latin small letter dz. Они предназначены для совместимости с югославскими кодировками, поддерживающими транслитерацию македонского языка, где диграф соответствует кириллической букве Ѕ.

– https://ru.wikipedia.org/wiki/Dz

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

Поэтому утверждая, что нет, не удобно, не нужно, давайте отменим — вы не со мной спорите, а с реальностью. Ну, успеха, чё.

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

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

Погодите!

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

Хорошо, что нас упорыши из M$ не читают. А то могли бы и принять на вооружение эту идею. Поосторожнее с таким — никогда не знаешь, что этим светлым умам в голову придёт взять да и воплотить в жизнь :)

Только что ввёл «новый документ.txt» в поиске своего браузера. Он сматчил все три вхождения. В чём различие кроме регистра?

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

Мне кажется, что это лишнее. Кейс не частый.

Я, вот, про неявные преобразования регистров тоже так думаю.

На клавиатуре 26 символов в верхнем регистре и только один пробел. По-моему, разница значительная.

На клавиатуре вообще нет символов в верхнем регистре.

Вот именно! Это аргумент в пользу того, что можно обойтись одним - это кое-что упростит (например, уменьшит размер клавиатуры).

Кто-то забывает как пишутся буквы, а кто-то (я) забывает как выглядит клавиатура.

Вот именно! Это аргумент в пользу того, что можно обойтись одним - это кое-что упростит (например, уменьшит размер клавиатуры).

Как это уменьшит размер клавиатуры?..

Ты шифт хочешь убрать? На 1% уменьшить?

Или о чём ты вообще…

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

Зачем?

Можно обойтись вообще без компьютеров. Да и без письменности.

Чтобы воплотить идею регистрозависимости ещё и в клавиатуре :)

if file.extension.to_lower() == ‘txt’

Я не спорю с тем, что это работает. Я говорю о том, что тысячи скриптов, использующих \.txt$ в своей обработке, не работают.

А “extension” аккуратно маскирует проблему извлечения расширения.

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

Позволю вставить цитату Линуса на другую тему, но схожим намерением 1:

“...filesystem people should aim to make “badly written” code “just work” unless people are really really unlucky. Because like it or not, that’s what 99% of all code is... Crying that it’s an application bug is like crying over the speed of light: you should deal with *reality*, not what you wish reality was.”

Алсо тут на сцену врываются врываются t×t, tⅹt, tｘt, ᵗˣᵗ ну и так далее

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

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

Нет, шифт можно оставить, но сделать например чтобы он добавлял 13 к номеру буквы. shift+A = N, shift+B = O, shift+C = P , ... shift+M = Z. А лишние 13 кнопок убрать. Кстати так будет проще заголовок exe файла набирать: M, shift+M.

Чтобы воплотить идею регистрозависимости ещё и в клавиатуре :)

Зачем?

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

Не надо. Слишком разрешающая система будет разнородной: один в лес, другой по дрова.

Но в случае с регистром нам и угадывать ничего не нужно. open("settings.json") и open("Settings.json") работают идентично. Один централизованный компонент может себе позволить хорошую сложную обработку, чтобы разгрузить клиентов. Проблема начнётся, когда эта абстракция начнёт протекать и клиентам придётся её повторять. В случае с регистром протечка небольшая: данные можно нормализовать как можно раньше. А вот если допустить условное setting.jsons, то нормализация не поможет, потому что у всех будут разные представления о норме.

наверняка была какая-то очень умная задумка

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

И строгость и отсутствие путаницы одновременно и автодополнение в терминале лучше работает.

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

Слишком разрешающая система будет разнородной: один в лес, другой по дрова.

Вот именно.

Но в случае с регистром нам и угадывать ничего не нужно. open(«settings.json») и open(«Settings.json») работают идентично

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

Гораздо логичнее и проще выкинуть все вообще частные случаи. Имя файла состоит из определённых букв в определённом порядке. Всё.

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

правда в споре а до истины, как до солнца пешком

а я вот не помню в дос были регистронезависмые имена файлов или зависимые ?? почемуто помнятся только имена в КАПСЛОКЕ :)

ага вот оно
https://ru.wikipedia.org/wiki/ASCII#История

Работа по созданию ASCII … была опубликована его первая редакция (ASA X3.4—1963)[8]. В ней отсутствовали строчные буквы, а область из 28 кодовых позиций 0x60—0x7B была зарезервирована для дальнейшего использования. Велись споры о том, как использовать эту область — для добавления строчных букв или же управляющих символов.

стхнскйтчкзрнтпрв мншсмвлв=мншv мншv=кнмрсрсв прфт

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

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

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

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

+1 проверка при создании новых файлов. Небольшая плата за удобство и отсутствие ошибок из за регистра.

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

чуть выше уже было упоминание про разнообразие проеблов в UTF.

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

руководствуясь синдомом утёнка

Я в последний раз работал с виндой очень давно и о регистре символов вообще не думал. macOS же наоборот сломал мою привычку работать с зависимым регистром. Так что всё наоборот.

А что в макоси думают об ударениях? «Новый докуме́нт.txt» и «Новый доку́мент.txt» это два файла или один? И, главное, почему?

Эти древние косяки нам ещё долго аукаться будут.

Небольшая плата за удобство и отсутствие ошибок из за регистра

имхо, это не правильно!
расчитывать на изначальное распи$$$дяйство и надеяться что «система» будет работать «правильно» - это какое-то идиотство и садомазохренизм!
есть правила, обычно (:о) их придумывают не дураки и ... просто надо их соблюдать (та-же ТБ вспоминается)

Нужно делать так, как нужно. А как не нужно, делать не нужно! (Виней Зе Пух)

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

p.s. надеюсь, не сильно резко? т.е. это относиться к основной, имхо, «неправильной идеи» и не к «личному иному мнению».

macOS же наоборот сломал мою привычку работать с зависимым регистром

можно примеры? (без стеба, просто интересуюсь)

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

Придумывают не дураки, а среди тех кто их должен соблюдать, совершенно разные люди, среди которых не мало и дураков и просто невнимательных людей. Защита от дурака, слышал такое понятие?

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