Изменение никнейма

Дата регистрации: 07.04.19 17:45:59

Не проще ли перерегаться?

Проще.

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

А вот это разумно

На линуксофоруме делать ники регистронезависимыми? Язабан.

Ты не против, если я зарегаю Alexferman с такой же авой, и буду тупить во всех темах?

Не против.

На линуксофоруме делать ники регистронезависимыми?

ЕМНИП, из-за того, что так не сделали сразу, к ЛОРу теперь не прикрутишь ни Jabber, ни OpenID. Обсуждали же вроде как.

Не проще ли перерегаться?

Deleted

Вот зачем ты человека плохому научил...

И кстати, не мог бы ты объяснить, какая польза от регистрозависимости имён файлов в линуксовых и вообще юниксовых ФС? По-моему, от неё одна только путаница.

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

Больше похоже на допущенный 40 лет назад дефект, который уже почти невозможно исправить, не сломав совместимость.

Согласен. Хрень полная.

И кстати, не мог бы ты объяснить, какая польза от регистрозависимости имён файлов в линуксовых и вообще юниксовых ФС?

В регистронезависимой системе IS и is - это одинаковое имя файлов или разные?

https://en.wikipedia.org/wiki/Dotted_and_dotless_I

не мог бы ты объяснить, какая польза от регистрозависимости имён файлов в линуксовых и вообще юниксовых ФС?

Это просто удобно.

Регистрозависимость, внезапно, это отличная вещь, которая способствует стандартизации.

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

Достаточно взглянуть на словесный понос в SQL, CMake DSL и прочих языках, где все пишут по разному:

TARGET_LINK_LIBRARIES(program mylib)

target_link_libraries(program mylib)

Target_Link_Libraries(program mylib)

Target_link_libraries(program mylib)

Чтобы восславить регистрозависимость. С файлами ситуация аналогичная.

Убожество:

#include <STDAFX.H>
#include <Conio.h>
#include <Iostream.h>

В регистронезависимой системе IS и is - это одинаковое имя файлов или разные?

Одинаковое. И что? Не совсем понял, в чём меня должна убедить твоя ссылка - там же не различия между большими и маленькими буквами обсуждаются, а различия между разными i (да, там возможна путаница, но она явно другого происхождения).

Чтобы восславить регистрозависимость.

И при этом ты приводишь примеры где регистрозависимость всё портит.

Убожество не в этом, а в том, что один и тот же исходник (в котором как раз написано <Iostream.h>) в винде компилируется, а в линуксе нет.

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

Да, в принципе, это решается всякими VCS и системами документооборота, но куда правильнее было бы не создавать зацепку для путаницы.

куда правильнее было бы не создавать зацепку для путаницы

Вот это верно, винде давно пора перейти на регистрозависимость.

И кстати, не мог бы ты объяснить, какая польза от регистрозависимости имён файлов в линуксовых и вообще юниксовых ФС? По-моему, от неё одна только путаница.

Ты другим концом ставишь вопрос. Для реализации регистронезависимости нужно больше телодвижений (пример с туркоазербайджанской латиницей уже привели). Следовательно, состояние по умолчанию — это регистронезависимость.

Одинаковое.

Неправильный ответ.

В турецкой локали - разные имена.

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

Путаница там на уровне кодов символов. Интерпретация принадлежности кодов к одной букве зависит от локали.

Поехали дальше, что ты будешь делать, когда завтра в юникод добавят очередной новый алфавит? Интерпретация имён будет зависеть от версии установленного пакета? Обновился - всё работает. Не обновился - «у вас ошибки на ФС / в архиве tar, мы не знаем такие буквы».

Файловая система в unix-подобных системах работает на правильном уровне абстракции - записывает имена как поток байт без попытки интерпретации. Это позволяет делать прямую и обратную совместимость хранилища данных, протянутую через десятилетия.

Если приколотить туда интерпретацию символов, всё будет разваливаться и глючить.

Для реализации регистронезависимости нужно больше телодвижений

Следовательно, состояние по умолчанию — это регистронезависимость.

Чё?

Убожество не в этом, а в том, что один и тот же исходник (в котором как раз написано <Iostream.h>) в винде компилируется, а в линуксе нет.

Всё правильно, если ты засрал свои инклуды чем-то вроде:

#include <IoStReAm.H>

Система должна бить тебя по пальцам, чтобы ты сделал стандартизировано. И она это делает.

А если ещё подумать, то при различных файловых операциях в регистронезависимых системах дёргается какой-нибудь абстрактный toLower(), то при ситуации Unicode everywhere это ещё и на производительности должно сказываться.

Если приколотить туда интерпретацию символов, всё будет разваливаться и глючить.

Линус кстати ругал macOS за эту херь:

Создатель Linux назвал файловую систему OS X худшей в мире, а разработчиков Apple – обезьянами

Но в macOS можно выбрать регистрозависимую модель. А вот можно ли в винде – не в курсе.

Для реализации регистронезависимости нужно больше телодвижений (пример с туркоазербайджанской латиницей уже привели). Следовательно, состояние по умолчанию — это регистронезависимость.

Угу, ключевые слова — «для реализации». А может, правильнее отталкиваться не от реализации, а от того, как правильнее?

Критерии правильности в студию

Система должна бить тебя по пальцам, чтобы ты сделал стандартизировано. И она это делает.

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

а от того, как правильнее?

Критерии правильности в студию

Поехали дальше, что ты будешь делать, когда завтра в юникод добавят очередной новый алфавит?

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

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

a == A Это хорошо? O_o А какая польза от регистронезависимых?

ХоТя МоЖНа пиСаТЬ ТакИм клВым ТекстТом!

/*И дажИ пагРаМиРовать!*/
#IncluDe "AweSOMEiNMclude.h"

iNt MAiN(VoID)
{
   PRintF("hEllO wOrld");
   File * fFf = foPen("/SyS/proC/cpUinFO","Rw");
   ASSErt(fff);

   iNt abc = 42;
   Int AbC = 25// UuuuuPssss!

rETurn 0;
}

::)

Опечатался маленько.

листинг

Похоже на типичный CMakeLists.txt.

::)

Языки эволюционируют постоянно. И не для всех еще устоялась письменность.

А там, где устоялась, бывают реформы.

Если Missstand и missstand считать одним именем, то какие основания считать Missstand и Mißstand разными именами? До какого уровня интерпретации нужно дойти, прежде чем остановиться? Интерпретировать все диграфы и лигатуры?

В некоторых языках нет различия заглавных и прописных букв вообще, в некоторых нет различия только у НЕКОТОРЫХ букв, в некоторых - сложная система, не выписывающаяся в наше бинарное деление.

В ядро Linux для ФС Ext4 включена поддержка работы без учёта регистра символов

Тед Цо (Ted Ts'o), автор файловых систем ext2/ext3/ext4, принял в ветку Linux-next, на основе которой будет сформирован выпуск ядра Linux 5.2, набор изменений, реализующих поддержку регистронезависимых операций в файловой системе Ext4. Патчи также добавляют поддержку символов UTF-8 в именах файлов.

Режим работы без различия регистра символов опционально включается в привязке к отдельным каталогам при помощи нового атрибута «+F» (EXT4_CASEFOLD_FL). При установке данного атрибута на каталог все операции с файлами и подкаталогами внутри будут производиться без учёта регистра символов, в том числе регистр будет игнорироваться при операциях поиска и открытия файлов (например, файлы Test.txt, test.txt и test.TXT в подобных каталогах будут считаться одинаковыми).

Интересно. Ну, так как это опция, ничего страшного не случится, если код не распознает регистронезависимость или не поддерживает ее совсем.