Соответствует ли утилита rsync философии unix?

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

Можно примеры?

Там огромное количество вариантов настроек, и много способов разных применений.

Разверните мысль пжлст.

Может быть имело смысл делать несколько разных утилит вместо этой одной?

Нет. Точно нет.

git для дифов текстовых файлов

Нет, гит не для диффов. Для диффов diff.

Если бы вы проектировали новую операционную систему, как бы вы поступили?

rsync это не базовая утилита ОС, это прога которую отдельно ставят когда она нужна

Может быть имело смысл делать несколько разных утилит вместо этой одной?

Сделай, если хочешь, можно даже форкнуть rsync для этого. А вот спросом вряд ли будет пользоваться.

Соответствует не полностью, но и не противоречит ей. Не меньше, чем GNU-тые проекты, короче.

Соответствует ли любой современный мессенджер философии unix?

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

Может быть имело смысл делать несколько разных утилит вместо этой одной?

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

Если бы вы проектировали новую операционную систему, как бы вы поступили?

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

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

С rsync'ом вполне можно было бы поставлять скрипты (или вообще алиасы) по примерным подгруппам задач. Типа rsync-server, rsync-tuda и rsync-suda, лень продумывать, но идея понятна. Что-то подобное, емнип, сделано, например, в elfutils. И в 7zip тоже.

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

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

По крайне мере установка rsync необязательна.

Плюсую. Не пользуюсь rsync.

Мои юзекейсы исчерпываются scp, tar, cp.

Особо часто пользуюсь ключиком -n к cp. При его использовании не перезаписываются заново уже существующие на целевом носителе файлы.

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

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

А mv не только переименовывает файлы,но еще и перемещает их!

Зогпретить!!!

Только если он из состава емакс.

А что подразумевается под чем-то новым?

После вкорячивания в Линукс дистры глючного комбайна X.Org (а до этого было XFree86), говорить о неюниксвейности rsync неактуально.

Поправил.

Может быть имело смысл делать несколько разных утилит вместо этой одной?

Так сделай симлинки или скрипты-однострочники с параметрами для rsync.

А что подразумевается под чем-то новым?

В сравнении с принципами UNIX, чем-то новым будут гуй и сети.

нейро!!! сети

нейро!!! сети

Да, и гуй тоже не на г.

В гну ничего не соответствует философии UNIX. Любую утилиту возьми - миллион опций. Да взять даже банальный cat. Зачем там имя файла первым параметром, если его можно редиректом передать?

Зачем там имя файла первым параметром, если его можно редиректом передать?

Потому что редиректом в cat уже передаются другие данные.

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

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

Ты бы хоть проверил, прежде чем писать. Если передаётся имя файла, то stdin игнорируется.

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

Ты бы хоть проверил, прежде чем писать. Если передаётся имя файла, то stdin игнорируется.

Как это отменяет тот факт, что cat таки читает stdin?

Единственный юз-кейс, когда нужно передавать имена файлов - «склеивание» нескольких файлов.

Ну, да. От утилиты [con]cat[enate] (склеить) удивительно требовать что-то другое. Хотя я постоянно пишу cat file | grep pattern вместо grep pattern file.

Буй и рыболовные сети!? Ибо в сокеты долбится где придумали?

Как это отменяет тот факт, что cat таки читает stdin?

Я тебя не понимаю.

я постоянно пишу cat file | grep pattern вместо grep pattern file.

А должен писать grep pattern < file, юникс-вей же. А второй параметр у grep надо отрезать. И вообще весь этот grep надо отрезать, есть же awk.

Я тебя не понимаю.

Ты никогда не видел something-something | yada-yada | cat ?

Я говорил о том, что вариант вызова cat с одним параметром в виде файла, как это делают в 99% случаев - не нужен. Всё, что нужно от cat (пока мы не говорим про соединение нескольких файлов) - это копировать stdin в stdout. Если нужно вызвать cat с одним параметром в виде файла, то это всегда можно заменить редиректом.

Безотносительно вышесказанного - ... | cat я никогда не видел и теряюсь в догадках - зачем это может быть нужно.

Есть такая жизненная концепция, «начни с себя». Так вот, а ты соответствуешь философии юникс?

Безотносительно вышесказанного - ... | cat я никогда не видел и теряюсь в догадках - зачем это может быть нужно.

Часто программы меняют свой вывод в зависимости от того, выводят ли они в терминал или в трубу. Напр. ls.

Я говорил о том, что вариант вызова cat с одним параметром в виде файла, как это делают в 99% случаев - не нужен.

Ты хочешь вставить в cat код типа if (argc < 3) { die("YOU'RE DOING IT WRONG"); } ? :DDDDDD

Безотносительно вышесказанного - … | cat я никогда не видел и теряюсь в догадках - зачем это может быть нужно.

Ооооо… Например, если команда перед cat ведёт себя по-разному в терминале и в пайпе. Сравни поведение git grep <pattern> и git grep <pattern> | cat, например.

Ты хочешь вставить в cat код типа if (argc < 3) { die(«YOU’RE DOING IT WRONG»); } ? :DDDDDD

Звучит глупо, согласен. Я больше про концепцию. Я бы предложил cat выкинуть вовсе ну или сделать весь его функционал копированием stdin в stdout, а конкатенацию возложить на плечи shell-а. cat <f1.txt <f2.txt >f12.txt.

Ооооо… Например, если команда перед cat ведёт себя по-разному в терминале и в пайпе. Сравни поведение git grep и git grep | cat, например.

Да, затупил, помню такое, хотя и редко нужно. По-мне все эти разные поведения это тоже фигня какая-то.

Я бы предложил cat выкинуть вовсе

Ну выкинь. Кто ж тебе мешает-то?

cat <f1.txt <f2.txt >f12.txt.

И чем это лучше cat f1 f2 > f3 ?

По-мне все эти разные поведения это тоже фигня какая-то.

Подсветка синтаксиса в выводе – фигня? Или подсветка директорий и файлов в выводе ls разными цветами – фигня? Или что именно? В случае с git, при выводе в терминал git вообще дёргает $PAGER.

Потому что stdout предполагается для чтения человеком.

Открой для себя 9p.

это какая-то старая древная деталь из состава qemu и ей там уже придумали альтернативу

А с правами и другими линками как обходитесь?

не только под юникс
Но после победы над виндой и яблом.

Нескромный вопрос, а у ябла какое ведро?

деталь из состава qemu

Иди в школу.

А с правами и другими линками как обходитесь?

Если делаю бэкап системы, то пользуюсь tar-ом. Он права и линки нормально «кушает».

А если бэкаплю файлы, то cp -a или cp -an в зависимости от обстоятельств.

забудь тар в его каменном веке. use squashfs luke !!

Спасибо, посмотрю.

А если бэкаплю файлы, то cp -a или cp -an в зависимости от обстоятельств.

Я при использовании cp ещё ключик x использую, cp -ax

Местячково специфично, может да, а может и нет, а tar робит на любой никс системе.

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

Посмотрел я здесь: https://unix.stackexchange.com/a/731610/445802

Автор обширно рассматривает различные варианты архивирования. При этом tar достаточно серьёзно рассматривается как архиватор. В том числе с различными способами компрессии. (Я использую, к примеру, pigz, но готов рассмотреть другие варианты.)

Из явных фич squashfs, как я понял, это лёгкость доступа к отдельным файлам архива. Чтож, серьёзный аргумент, но, скорее, для тех, кому эта фича нужна.

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

Пара гиг? Вы с терабайтами не перепутали? Пара гиг может быть неудобной если пережали под ноль или с ленточек восстанавливаете.

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

Я тоже по разному жму или вообще не жму, в зависимости от...

Я использую, к примеру, pigz

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