Обновил Дебиан

необходимость знать одновременно и BRE, и ERE — просто комедия.

Вот кстати в написании заковыристых регулярных выражений таки неплохо помогает ИИ. Как и в объяснении написанных кем-то другим.

к сожалению

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

Вероятно, автоматический апгрейд не справился

нет. Никаких «автоматических апгрейдов» я не пробовал.

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

Вот кстати в написании заковыристых регулярных выражений таки неплохо помогает ИИ.

Большое регулярное выражение удобно лишь писать, а ты предлагаешь вычитывать галлюцинации ИИ?! Нет, спасибо.

предлагаешь вычитывать галлюцинации ИИ?!

Он сам отлично умеет вычитывать и объяснять что делает особо зубодробительное регулярное выражение. В этом и ценность для тех кто в обычной жизни на регулярных выражениях не специализируется.

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

Согласен, если просто узнать. Я так javascrip редактирую в гноме — просто прошу ИИ найти нужное место и подсказать, что туда написать.

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

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

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

Бардак проще не допускать чем потом его разгребать. Языки программирования налагают много всяких ограничений,однако ими пользуются. Хотя казалось бы пиши на ассемблере - там всё что угодно можно делать лишь бы железо позволяло. Или поближе к теме пример - в линуксе таки внедрили стандарт расположения компонентов в файловой системе и все стараются его придержиматься. Хотя во времена вин95-98 ничего подобного небыло и каждый пихал свои файлы куда хотел. Да и в ранних линуксах тоже бардака с расположением файлов хватало.

Или поближе к теме пример - в линуксе таки внедрили стандарт расположения компонентов в файловой системе и все стараются его придержиматься.

Однако, никто не запрещает его не придерживаться и тем более не проверяет что-то там при создании файла.

Из-за таких, как ты, только в M$, мне при создании торрентов приходится ? и даже : из имён файлов убирать, потому что в некоторых говноосях оно запрещено (без адекватных причин, просто чтобы поднасрать). Спасибо хоть, что пробел не приходится.

Тебе никто не запрещает именовать файлы по принципа DOS — 8 ASCII-символов на имя и ещё 3 на расширение, если нравится. Ничто не мешает написать скрипт, который будет все файлы так переименовывать. Только не надо это всем навязывать.

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

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

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

мне при создании торрентов приходится ? и даже : из имён файлов убирать

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

Тебе никто не запрещает именовать файлы по принципа DOS — 8 ASCII-символов на имя и ещё 3 на расширение

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

Кстати,для приведения имен файлов в порядок есть даже специальная программа detox

https://linux.die.net/man/1/detox

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

Простите, но я считаю себя вполне квалифицированным пользователям, и я сомневаюсь, что вам удастся меня убедить в обратном. И я уж точно прекрасно знаю обо всех последствиях (кроме тех, что по вине M$. Точнее и о них знаю, но они напрягают).

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

1. А на мой — не очень.
2. Идентификаторы в программе и имена файлов это разные сущности, и не нужно их мешать в кучу.

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

записывались на ext4 как разные. А при копировании на флэшку fat32 для использования в автономном проигрывателе - перезаписывались один поверх другого.

Такое может быть и на совсем не «заковыристых» именах. Основная проблема здесь в том, что ext4 — нормальная файловая система, а fat32 — досовско-виндоидная. И самым основным отличием в ней является нечуствительность к регистру. То есть, FileName.txt, filename.TXT и filename.txt — это три разных файла на ext4 по умолчанию (и подавляющем числе других ФС), но один на fat32.

я считаю себя вполне квалифицированным пользователям

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

Идентификаторы в программе и имена файлов это разные сущности

В чем приницпиальная разница с точки зрения именования? Особенно учитывая что например при программировании на баше имена файлов могут становиться идентификаторами в программе. Тут-то и огребаем проблемы неразумного именования.

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

Я дал им такие имена сам. Самостоятельно и осознанно.

В чем приницпиальная разница с точки зрения именования?

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

fat32 — досовско-виндоидная.

Тем не менее именно она применяется на флэшках и именно только ее понимают всякие разные автономные девайсы от mp3 плейеров до видеорегистраторов и фотоаппаратов.

нечуствительность к регистру

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

Тем не менее именно она применяется на флэшках

На флэшках применяется какая угодно ФС. На моих, например, fat32 не применяется. Более того, она ещё и файлы больше 4 ГБ не поддерживает, то есть не годится для много чего, в первую очередь для кино.

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

Печально, когда так. Но это проблемы таких девайсов.

Но эта проблема решается скриптом, переименовывающим файлы при копировании на такой девайс. Более того, логично там не просто переименование делать, но и что-то ещё. Ну вот например, из FLAC в Opus или AAC конвертить и переименовывать (потому что FLAC на этом портативном девайсе нафиг не нужен, там не услышишь разницы, и потому что имена он хочет «особые»). А не корёжить нормальные имена на основном хранилище.

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

Мы здесь не придём к согласию. Я считаю, что нынешняя ситуация — отличная и не требует никакого исправления (за исключением того, что лучше бы досов с виндами и ихней fat32 никогда не существовало). Принцип «имя файла может быть любой последовательностью байт, за исключением слеша (используется как разделитель в пути, то есть так же является частью пути, просто имеет специальное значение) и байта 0x00 (конец строки)» считаю простым, правильным и не требующим никаких вмешательств. ФС в принципе не должна знать о каких-то там «буквах» — это забота прикладного софта (включая и такие особо абстрактные вещи, как регистр).

Я дал им такие имена сам. Самостоятельно и осознанно.

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

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

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

А можете как технически грамотный человек объяснить зачем вы дали им такие именя заведомо зная что это может привести к проблемам?

Я знаю, что не может (за исключением описанной — когда приходится делиться этими файлами с виндузятниками — и эту проблему создали M$).

Но вам-то это зачем?

Затем, что это попросту удобно. Название произведения (дополненное суффиксом по типу файла, например .flac или .mkv) — это очевидное, практиченое и наиболее логичное имя для файла. Выдумывать какие-то правила преобразования нормальных названий в каличные не имеет никакого смысла. Ну кроме случаев, когда надо поделиться этими файлами с виндузятниками — но в таких случаях собственно при этом процессе (в данном случае при создании торрент-файла, например) эти специфические манипуляции и стоит производить.

Название произведения (дополненное суффиксом по типу файла, например .flac или .mkv) — это очевидное, практиченое и наиболее логичное имя для файла.

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

ФС в принципе не должна знать о каких-то там «буквах» — это забота прикладного софта

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

и эту проблему создали M$

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

Затем, что это попросту удобно.

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

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

Печально, когда так. Но это проблемы таких девайсов.

К сожалению,в портативные девайсы на микроконтроллерах часто физически невозможно засунуть поддержку сколько-нибудь сложной файловой системы типа той же ext4 или даже ntfs(просто код в контроллер не влезет). А даже там где возможно - это приведет к большему потребления вычислительных ресурсов и следовательно энергии,а значит сократит время автономной работы. Также снизится скорость записи файлов на носитель,что может быть критично (фото/видео). Кстати,также по причине ограниченности ресурсов в микроконтроллерных девайсах по сей день преобладают однобайтовые кодировки символов. А к примеру знакосинтезирующие индикаторы - поголовно все такие. Там в железе «байт»==«символ».

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

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

Имя нужно только для процессов копирования/архивирования/передачи файлов.

Нет, не только.

И оно должно быть удобным именно для этих целей,а не для смотрения на него глазами.

Но нет ничего плохого в том, чтобы оно было удобным для смотрения на него глазами. Ровным счётом.

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

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

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

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

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

Они совпадают с большинством.

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

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

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

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

Нет, изображению обложки не место в тегах.

Я с вами согласен. Однако при скачивании файлов с mp3-файлопомоек такое встречается и не так редко как хотелось бы. Да еще из-за рукожопия тех кто файлы создавал - обложка занимает места чуть ли не столько же сколько музыка. Приходится вычищать. Ибо даже если в целевом девайсе место и есть то время копирования критично - девайсы обычно не быстрые.

Но файлу всё ещё нужно удобное и логичное название.

Согласен.

Название произведения идеально для этого подходит.

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

если бы не было M$, этой проблемы не возникало бы

В поголовно всех проприетарных системах с которым я работал за тридцать лет у компов - были те или иные ограничения на имена файлов. Начиная аж с ЕС ЭВМ (система MVT).

Они совпадают с большинством.

Нынче «большинство» за компами - это люди далёкие от вычислительной техники именно как области техники. Они плохо представляют себе отдалённые технические последствия своих хотелок. Это не только к именам файлов относится.

Корректность отображения файлов в кодировке UTF-8 никак не зависит от наличия или отсутствия «русского языка»

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

Я не знаю что такое «хоть сколько-то установлена инсталятором», но кому-то нужно пить меньше

В оригинале было:

«Если система хоть сколько-нибудь отличается от установленной инсталлятором в состоянии по умолчанию»

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

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

Говнодевайсам — говнофайлы. Эта проблема решается переименованием при копировании файлов на подобное непотребство. Корёжить их в месте постоянного хранения для этого не требуется.

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

А тот случай международной разборки происходил в 1996 году

Ну с этого надо было начинать :)

А тот случай международной разборки происходил в 1996 году

Ну с этого надо было начинать :)

А вы уверены что сейчас абсолютно везде вне РФ установлены шрифты содержащие кириллицу и что именно они назначены для отображения имен файлов во всём софте? Если у нас в России компы регулярно показывают квадратики вместо китайских иероглифов (почему-то не всех а как-то рандомно) то почему в других местах такого не будет с кириллицей?

абсолютно везде

До абсурда доводить не надо, абсолютного не бывает, и найти можно всё, что угодно.

Но где-то 99.5–99.9% случаев будет шрифт с поддержкой юникода. Есть некоторый шанс не увидеть поддержку китайского (очень много символов, не во всех шрифтах есть), но латиница, кириллица, греческий и иврит — это прям база, их отсутствие прощают только всяким вычурным «декоративным» шрифтам, как правило. К тому же в современных системах это работает не совсем так: если в выбранном шрифте нет какого-то символа, то этот символ берётся из другого шрифта, имеющегося в системе — это иногда может выглядеть немного инородно (начертание шрифта отличается и т.д.), но читабельно. И в подавляющем числе случаев в системе таки есть какие-нибудь Noto и Droid, покрывающие юникод.

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