Список легаси не логичного поведения и проблем?

Можно удалить загрузчик

«Знаешь Миша, а можно еще хер себе дверью специально прищемить и потом всем рассказывать про неправильные двери» (c) Sun-ch

«А ещё можно вызубрить почти безопасный путь по минному полю и потом всем рассказывать про то как всё хорошо» (с)Stahl

gzip по дефолту удаляет архив

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

Любое неявное действие – плохо. Неявное деструктивное действие – неприемлемо.

Пардон, -k ключ. Напутал.

Архива при этом давно нет уже)))

В случае gzip – это очень нужная, полезная и логичная фича.

Полезно было бы наоборот. Ключ для удаления

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

А ещё можно опечататься и ввести sudo rm -rf /usr /local/bin/myprogramm, например. Дальше что?

В Linux нет каких-то отдельных примеров «не того» поведения, он просто целиком рассчитан на то, что оператор не дурак, читал маны и ОС не нужно от него защищать.

А то так можно начать жаловаться что mv без ключа удаляет исходный файл.

И даже спросит пользователя? Опять же вижу что без ключа выйти с ошибкой а с ключом -f удалять.

можно начать жаловаться что mv без ключа удаляет

Нельзя, посокольку move по самой сути понятия предполагает удаление.

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

«Минное поле» - это если в документации не написано. Тогда это естественно плохо.

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

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

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

(а дефолт этот с удалением архива существует скорее всего ещё с древности когда место экономили или типа того, а не потому что кто-то там рассчитывал что систему будет использовать только академик)

нелогичного поведения

ssh -p 22

но

scp -P 22

Набивать себе шишки а потом убедить себя что это логично. Ну такое себе.

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

Если система это минное поле, которое может вести себя непредсказуемым образом, то это плохая система.

Если система ведет себя абсолютно так, как написано в документации и в этом есть логика(а в случае gzip - она есть) - не вижу никаких проблем.

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

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

Это повод, на выбор: 1) написать алиас(gzip -k);
2) убедить разработчиков поменять дефолт;
3) написать свою реализацию/использовать другой софт;

Но большинство в этом треде предпочитает универсальный вариант:

4) страдать и жаловаться.

Тут понимаю, тут вопросов нет...

Ты на всё в мире не прочитаешь документации.

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

4. страдать и жаловаться.

Не перекручивай. Никто тут не страдает. Кому это мешает, тот давно уже проблему решил тем или иным способом. Я, например, просто не использую gzip. Есть достаточное количество более удобных для меня инструментов.

Но это не оправдывает размещения карты минного поля на дверях подъезда вместо разминирования. Нет, обратная совместимость не всегда важна и логика «Тут всегда было минное поле, зачем его разнировать?» – не очень хороша.

Проблема вся в том, что, как я уже сказал, не все считают что это минное поле.

Так можно ко многому докопаться. Например, почему в той же Cisco один интерфейс не может быть по умолчанию и входной и выходной точкой для NAT-а? Или зачем это «убогое» разбиение на mangle/nat/filter в iptables?

Если любую особенность конфигурации, не совпадающей с собственными хотелками, обзывать минным полем - то тогда минное поле везде :-)

Я не вижу проблемы. Меня, как и большинство пользователей, устраивает текущее поведение gzip. Тебя не устраивает - ты используешь другой софт. Все счастливы. Где минное поле? Или ты считаешь, что все должны делать только так, как ты хочешь? Ну тода ой. Это так не работает.

У gzip логичное поведение.

А для rm емнип нужно создать спец файл корне против rm -rf /

└─> rm -rf /
rm: опасно рекурсивно обрабатывать '/'
rm: используйте --no-preserve-root, чтобы отменить предупреждение об опасности

Если система ведет себя абсолютно так, как написано в документации и в этом есть логика(а в случае gzip - она есть) - не вижу никаких проблем.

Так тут обсуждается не качество ведения документации, а нелогичность поведения софта.
Если что-то описано в документации,то это ещё не значит, что оно спроектировано с учётом достижений UI/UX.

Но большинство в этом треде предпочитает универсальный вариант:

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

По ЛОРу можно диссертации психологам защищать, ей богу.

Ой, это бесит. Ещё у chown и chmod в какой-то работает и -r и -R, а в какой-то только -R

Приготовить чай и выкинуть чайник это не совсем то поведение которое ожидает юзер от команды «приготовить_чай».

Пока сам не обожжёшься, не поймёшь.
Ну и плюс считаешь себя шибко умным.

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

Например, некоторое время опцию --reflink=auto в утилите cp отказались ставить по дефолту, потому что пользователи, следи за руками, могут полагаться на умолчальное поведение(--reflink=none) чтобы делать резервные копии файлов в пределах одной ФС. Резервные копии... в пределах одной ФС... Очень надежно, ага!

Вот это - пример того, когда дефолт пора менять и логики в нём в нет. Слава Б-гу здравый смысл возобладал и с какой-то версии util-linux(с 2.36 кажется, точно не помню) дефолт там теперь вменяемый.

С gzip я такого не вижу.

которое ожидает юзер от команды «приготовить_чай».

 The  gzip command reduces the size of the named files using Lempel-Ziv coding (LZ77).  Whenever possible,
       each file is replaced by one with the extension .gz, while keeping the same ownership modes,  access  and
       modification  times.

То что пользователь вызывает команду «заменить_мне_файл_сжатой_версией» и жалуется, что старый файл удалили - это проблема пользователя

Вообще-то rm удаление. А mv это перемещение или переименование обычно.

По ЛОРу можно диссертации психологам защищать, ей богу.

Ещё один всё понял.

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

Если система ведет себя абсолютно так, как написано в документации и в этом есть логика(а в случае gzip - она есть) - не вижу никаких проблем.

А чё ж тогда всем ЛОРом несчастных реактосовцев поливали за то, что у них система в virtual box’е не работает из коробки? А ведь они честно в документации написали, что нужно выбрать другой сетевой адаптер. И таки ж дополивали до того, что они написали драйвер и на сетевуху-vbox’а-по-умолчанию.

Да брось ты, ну это же реально бред.
Это архиватор, от которого ожидают поведения архиватора.

(и думаю он не редьюс делает, а такие сначала создаёт новый файл и потом старый удаляет, но даже если не так, то это всё равно неправильное поведение именно с точки зрения UX)

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

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

Т.е. ты только про ротацию логов увидел... Вот только я не пишу для этого скриптов.

И что-то в моём мире gzip, bzip, lzma и прочие ведут себя ожидаемо и удобно. А в твоём ничего не удаляется.

chmod -r интерпретируется не как опция а как «убрать бит чтения у всех»

А чё ж тогда всем ЛОРом несчастных реактосовцев поливали за то, что у них система в virtual box’е не работает из коробки?

Шо, и я тоже?

И таки ж дополивали до того, что они написали драйвер и на сетевуху-vbox’а-по-умолчанию.

Польза hate-driven-development. Главное не частить с этим, а то можно нарваться на «ой, да мудохайтесь с этим сами» от разработчиков, после чего они сваливают в туман и бросают проект.

Ни разу не ставил reactos и впервые слышу про их проблемы в virtualbox.

Прямое действие: mount, обратное действие umount. Звучит нелогично. Можно было бы назвать обратное действие unmount или еще как-то. В Novell Netware для обратного действия команда называется dismount.

https://unix.stackexchange.com/a/9835

This dates all the way back to the very first edition of Unix, where all the standard file names were only at most 6 characters long (think passwd), even though this version supported a whooping 8 characters in a file name. Most commands had an associated source file ending in .c (e.g. umount.c), which left only 6 characters for the base name.

A 6-character limitation might also have been a holdover from an earlier development version, or inherited from a then-current IBM system that did have a 6-character limitation. (Early C implementations had a 6-character limit on identifiers — longer identifiers were accepted but the compiler only looked at the first 6 characters, so foobar1 and foobar2 were the same variable.)

(I thought I remembered a umount man page that listed the spelling as a bug of unknown origin, but I can’t find it now.)

всё нормально работает как и солнце с востока каждый день встает.
ну если не ССЗБ :-)

выглядит как троллинг :-))))

Ну… кагбэ, это он и есть.

Нельзя, посокольку move по самой сути понятия предполагает удаление.

А у gzip компрессия файла. Не copy файла в другое состояние, а именно move. И обратно. Т.ч. всё логично и понятно.

И ещё более понятно, что в отличае от сяких других arj, arc, zip и rar, gzip работает только с отдельными потоками (файлами) а не иерархиями и коллекциями.

gzip работает только с отдельными потоками (файлами)

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

Это некорректная аналогия. Лучше что-то в стиле: заморозить воду, разморозить лед

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

gzip не ариватор, gzip компрессор. Архиваторы для складирования эталонов - tar и cpio.

Слово архиватор в современном языке имеет другое значение.
Но эрудицию ты показал, молодчинка.

Твои рассуждения не делают из gzip и ему подобных архиваторов.

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