Кто идет на Unix-way (или пользователь Linux - кто он)

[t.t]

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

Я напишу замечательную мега-утилиту, которая умеет почти всё на свете, даже кофе варить, но она будет делать это не сама. Для архивирования — tar или cpio, для сжатия — gzip, bzip2, 7z, для сборки программ — configure, make, и др., для варки — coffee-machine какой-нибудь. И что, это будет Unix-way?

На мой взгляд, ты смешиваешь две большие разницы: tar вызывает другие программы для смежных задач (ключевое слово -- "смежных"). Кроме того, tar cj это совсем не аналог tar c | bzip2: во втором случае получаем сжатый архив, в первом -- архив сжатых файлов (в терминологии rar это называется solid archive (не помню, как по-русски) и обычным архивом соответственно). Если об этом не забывать, то настоящий аналог tar cj с помощью конвейеров не так просто реализовать; если вообще возможно без временных файлов.

[t.t]

Однако в рар-формат скорее всего лучше сжимает именно сам рар. И нет ни чего удивительного в задаче с условием использование конкретного архиватора. Я реально у клиентов встречался с таким требованием.

Я не спорил с тем, что такое требование может реально встречаться. Но оно не укладывается в unix-way.

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

Дело не в разделении задач архивации и сжатия -- тем более, что задачи эти действительно смежные. Начнём с того, что rar пытается выполнять не только эти задачи. Но ещё, например, шифрование по паролю. Которое ломается за пять минут без особых умений. А вот truecrypt или gpg выполняют одну только задачу шифрования -- зато качественно.

Да и не это главное. В rar (да и unrar) нарушены гораздо более важные принципы, и об этом выше уже писали. Нет работы через конвейер (т.е. со стандартного ввода, и на стандартный вывод). Нарушены устоявшиеся принципы разбора командной строки. И т.п.

Если говорить о "сжимающем архиваторе" в контексте unix-way, то уж не о rar точно. Но говорить можно. Например, о zip. У меня у самого есть для примера конкретная задача. Нужно хранить некоторое количество маленьких файлов в одном "контейнере". Файлы в основном текстовые, а в контейнере их (да и самих контейнеров) может быть много; так что нужно сжатие. Т.к. файлы текстоввые, то степень сжатия не критична -- она всё равно будет достаточной; важнее скорость. Казалось бы, tar + gzip подходят идеально? Ан нет. В процессе работы нередки ситуации, когда нужно подправить один или два файла внутри контейнера. Именно внутри; распаковывать и заново паковать весь контейнер -- не вариант, т.к. общий объём файлов в нём может превышать размер редактируемого файла на несколько порядков. Вот мы и упёрлись вограничение tar-а: он не умеет обновлять файлы в сжатом архиве. Зато подходит zip, который и в конвейерах можно использовать, что тоже важно.

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

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

[t.t]

Кстати, где-ж они выкопали такие утилиты?

unix-утилиты пишут не только GNU.

Зачем?
Зачем портить?

Вы, видимо, не совсем верно поняли. На мой взгляд, речь шла в том числе и о коммерческих unix-ах, таких как HP-UX или IRIX. Ни к GNU, ни к Linux они вообще никакого отношения не имеют.

Я даже не могу контролировать степень сжатия, встроенного в tar (tar|gzip — уже не встроенное).

Строго говоря, tar cz -- тоже не встроенное. И контролировать, строго говоря, можешь: у gzip есть переменная окружения.

[watashiwa_daredeska]

tar вызывает другие программы для смежных задач (ключевое слово -- "смежных").

Практически любой комбайн скомбинирован из «смежных» задач.

tar cj это совсем не аналог tar c | bzip2: во втором случае получаем сжатый архив, в первом -- архив сжатых файлов

Нет. Это полный аналог. Никакого «архива сжатых файлов». После tar cj точно так же работает bzib2 -dc | tar x, как и после tar c | bzip2.

[Voral]

Я не спорил с тем, что такое требование может реально встречаться. Но оно не укладывается в unix-way.

Вот и я о том: у нас разные взгляды на Unix Way.
Давайте уйдем (что бы объяснить мою позицию) от примера конкретных программ. Допустим есть программа (SomeApp) по сути комбайн, которая в виду каких либо причин выполняет определенное действие (в числе прочих) и аналогов в этом действии нет вообще. (достаточно реальный пример я приводил). Предположим она уже позволяет использовать ее в таком режиме (только для примера. в прочем вполне реального):

Код: Выделить всё

cat somefile | SomeApp | grep blablabla

вот в моем понимании это вполне юникс вейное решение. Хотя SomeApp не юникс вейное решение.


Между тем ни Вы не я не можем и не сможем убедительно доказать (да, наверное, в этом нет смысла) что именно своя точка зрения абсолютно верная.

[diesel]

в принципе, ваш пример с MS Word и IE7 не является примером unix-way, но не потому что эти программы комбайны, и умеют делать много чего. Здесь вопрос скорее к интерефейсу взаимодействия с внешнем миром.

В принципе, согласен. Но комбайновость нарушает принцип "одна программа - одна задача". Стало быть не Unix-way.

А вообще, интересно.
Сколько принципов нужно соблюсти, чтобы считалось по Unix-way?
И сколько принцпов нужно нарушить, чтобы считалось "не Unix-way?"

ИМХО, неправильный подход. Даже если ориентироваться ту же самую викепедию там есть несколько вариантов тезисного изложения того чем на самом деле этот unix-way есть. Нельзя просто пройти по девяти пунктам, посмотреть соответствует ли им программа и принимать решение о том unix-way это или нет, более того: принимать решение о том использовать программу или нет в решении своей задачи, ориентируясь на то соответствует ли она пунктам или нет - вообще глупость. Здесь критерий будет другой: насколько легко использовать программу в решении задачи, и нет ли другой программы, которую будет использовать легче.

Подборка пунктов в википедии - это просто попытка кратко описать культуру, которая сложилась вокруг использования UNIX-систем. Культуру многообразную, и неформальную, которая сложилась, передавалась и передается в основном собственно в процессе общения между людьми, и в процессе общения между человеком и его unix-системой. тут что-то типа "ваш подход не соответствует пукту 1/параграфу 2 нашей-супер-модной-концепции-разработки" подходит слабо.

к формальному подходу оценки unix-way'ности интересно добавить вопрос: является ли любой скрипт, созданный с использованием программ которые отвечают всем пунктам, в свою очередь unix-way'еем? Если рассматривать скрипт как "сборище нескольких программ" - то да, это даже рекомендуется делать. Если же рассматривать скрипт как отдельную программу, то не факт что все принципы интерфейса будут соблюдены, например, если не предполагается использовать его в pipe'ах, то вы врядли вложите в него возможность работать с stdin, и возможно он будет делать несколько вещей, не важно хорошо или плохо - достаточно для выполнения той группы задач для которой он создан.

А вот еще вопрос: если скрипт который использует другие программы вы признаете unix-way'ем, является ли вполне-себе-скомпилированная-программа, которая дергает другие программы таким же unix-way'ем? Здесь обругали один такой пример(не tar)

[t.t]

tar вызывает другие программы для смежных задач (ключевое слово -- "смежных").

Практически любой комбайн скомбинирован из «смежных» задач.

Нет. На примере тех же архиваторов: шифрование -- не смежная задача. Я понимаю, что во времена разработки первоначального tar-а сжатие тоже не было задачей, смежной с упаковкой, т.к. на ленточных накопителях несжатые архивы были удобнее. Но сейчас всё обстоит несколько иначе. См. пример с zip в моём ответе Voral.

tar cj это совсем не аналог tar c | bzip2: во втором случае получаем сжатый архив, в первом -- архив сжатых файлов

Нет. Это полный аналог. Никакого «архива сжатых файлов». После tar cj точно так же работает bzib2 -dc | tar x, как и после tar c | bzip2.

Да, прошу прощения. После того как написал вспомнил, что это не личный опыт, а сведения, почерпнутые из статьи или книги кого-то из известных русскоязычных авторов. Уже проверил сам на практике -- не подтвердилось.

[t.t]

Я не спорил с тем, что такое требование может реально встречаться. Но оно не укладывается в unix-way.

Вот и я о том: у нас разные взгляды на Unix Way.
Давайте уйдем (что бы объяснить мою позицию) от примера конкретных программ. Допустим есть программа (SomeApp) по сути комбайн, которая в виду каких либо причин выполняет определенное действие (в числе прочих) и аналогов в этом действии нет вообще. (достаточно реальный пример я приводил). Предположим она уже позволяет использовать ее в таком режиме (только для примера. в прочем вполне реального):

Код: Выделить всё

cat somefile | SomeApp | grep blablabla

вот в моем понимании это вполне юникс вейное решение. Хотя SomeApp не юникс вейное решение.

Между тем ни Вы не я не можем и не сможем убедительно доказать (да, наверное, в этом нет смысла) что именно своя точка зрения абсолютно верная.

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

Далее. Между Вашей и моей точками зрения есть существенная разница: Ваша совершенно оторвана от реальности. По Вашему примеру достаточно одной фразы: мне неизвестен ни один "комбайн имени звездатой кнопки", который можно было бы использовать таким образом, как Вы написали. Более того -- я подозреваю, что такого нет вообще. Если я неправ, приведите конкретный пример. Тогда будем разговаривать предметно. А тереотизирование о некой SomeApp, существующей лишь в Вашем воображении, считаю неконструктивным.

[Hephaestus]

Подборка пунктов в википедии - это просто попытка кратко описать культуру, которая сложилась вокруг использования UNIX-систем. Культуру многообразную, и неформальную, которая сложилась, передавалась и передается в основном собственно в процессе общения между людьми, и в процессе общения между человеком и его unix-системой. тут что-то типа "ваш подход не соответствует пукту 1/параграфу 2 нашей-супер-модной-концепции-разработки" подходит слабо.

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

[Hephaestus]

А вот еще вопрос: если скрипт который использует другие программы вы признаете unix-way'ем, является ли вполне-себе-скомпилированная-программа, которая дергает другие программы таким же unix-way'ем?

Сложно сказать. Смотря, какая программа.
Во всяком случае, скомпилированная программа не обладает гибкостью скрипта.
Если взять тот же конвейер "упаковка -> сжатие", то в случае скрипта это легко модифицируется: "упаковка -> шифрование -> сжатие" или "шифрование -> сжатие -> упаковка". Также легко заменятся версии программ или вообще одни программы на другие (аналогичные). В случае скомпилированной программы это сделать сложнее. Придется перекомпилировать. Не говоря уже, что нужно держать под рукой инструменты для компиляции и обладать знаниями по их использованию. Зачем усложнять и без того сложную вещь? Нарушается принцип KISS. Следовательно не Unix-way. ИМХО.

[Voral]

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

Ок. Повторю чуть подробнее.

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

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

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

Раскидывать проект на части нет времени, да и не вижу необходимости, все работает как есть. Я не сторонник переписывания ради ощущения причастности к некой философии (пусть и хорошей) Добавить поддержку для работу с пайпами. Это возможно. Более того для этого может найтись реальное применение. Например по крону опрос некоторого дополнительного состояния железяк, которое не нужно в основном протоколе передачи. Таким образом мы задействум одну единственную функцию опрос железяки. все.

Если что железяки из области энергетики....

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

[t.t]

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

Ок. Повторю чуть подробнее.

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

И снова та же ошибка... Точнее даже, целый набор ошибок:
1. Обсуждение любого пути невозможно в рамках одной отдельной ситуации;
2. Если в этой ситуации нет возможности применить некие уже готовые инструменты, то обсуждение "пути unix" невозможно тем более;
3. С другой стороны, даже попытаться взять эту отдельную ситуацию в качестве отправной точки для такого пути -- т.е. сейчас написать всё с нуля, но затем использовать те же готовые утилиты в других проектах -- и то невозможно.
Резюме: получаем даже не просто отдельную ситуацию, а ситуацию, которая в принципе не соединяется ни с какими другими по самой своей сути; т.е. вещь в себе. Какой же тут может быть путь? Даже идти некуда.

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

[Voral]

1. Обсуждение любого пути невозможно в рамках одной отдельной ситуации;

Это Вы попросили меня привести конкретный пример

2. Если в этой ситуации нет возможности применить некие уже готовые инструменты, то обсуждение "пути unix" невозможно тем более;

Можете считать что инструменты УЖЕ есть

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

Вы совершенно не поняли моего примера. Ни о каких других проектах не идет речь.

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

Вы просто не хотите меня понять. Я конкретно и четко сказал "я ни чего не доказываю". Я объясняю точку зрения.
Еще раз: С моей точки зрения. Факт использование в качестве инструмента комбайна, еще не горит о том, что решение не юникс вейное. И не важно возможна такая ситуация или нет. Определяющим фактом нахождения "на пути Юникс Вей" является лишь то КАК вы используете инструменты.

Факторов доказывающих мою неправоту нет. Я не видел в данной теме.

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

[Voral]

1. Обсуждение любого пути невозможно в рамках одной отдельной ситуации;

Или вы о том, что я someapp использую только в одной конкретной ситуации?
ТОгда пожалуста: тоже самое но с отправкой на мыло, то же самое но в архив; то же самое но выполнять действие в зависимости от содержимого вывода...

[t.t]

1. Обсуждение любого пути невозможно в рамках одной отдельной ситуации;

Это Вы попросили меня привести конкретный пример

Конкретный пример приложения, а не ситуации. Не путайте, пожалуста.

2. Если в этой ситуации нет возможности применить некие уже готовые инструменты, то обсуждение "пути unix" невозможно тем более;

Можете считать что инструменты УЖЕ есть

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

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

Вы совершенно не поняли моего примера. Ни о каких других проектах не идет речь.

Я всё отлично понял. Более того -- именно о том и говорю.

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

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

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

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

Еще раз: С моей точки зрения. Факт использование в качестве инструмента комбайна, еще не горит о том, что решение не юникс вейное. И не важно возможна такая ситуация или нет.

Как раз очень важно. Unix-way -- вещь сугубо практическая по определению: он и родился из практического опыта, и применяется для решения реальных практических задач реальными способами и инструментами. Теоретизировать о нём на примере воображаемых программ или воображаемых задач совершенно бессмысленно.

Факторов доказывающих мою неправоту нет. Я не видел в данной теме.

"Их нет" и "Вы их не видите" -- это разные вещи. У меня такое впечатление и складывается, что не в состоянии "увидеть", т.е. оценить те аргументы, которые приводятся многими участниками.

[t.t]

1. Обсуждение любого пути невозможно в рамках одной отдельной ситуации;

Или вы о том, что я someapp использую только в одной конкретной ситуации?

Нет, не о том. Тот пример я отмёл без обсуждения по причине его чистой воображаемости.

[watashiwa_daredeska]

мне неизвестен ни один "комбайн имени звездатой кнопки", который можно было бы использовать таким образом, как Вы написали. Более того -- я подозреваю, что такого нет вообще. Если я неправ, приведите конкретный пример.

aptitude
Вполне себе комбайн, даже «сапёр» встроен :)

[Voral]

Конкретный пример приложения, а не ситуации. Не путайте, пожалуста.

Я и привел пример конкретного приложения.

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

Круто. А все "реально юниксвейные программы" совершенно случайно оказались подходящими?

Резюме не игнорируйте, пожалуйста: Ваш пример -- это вещь в себе;

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

ни о каких путях на таком примере не может быть речи.

С вашей личной точки зрения да.

Как раз очень важно. Unix-way -- вещь сугубо практическая по определению: он и родился из практического опыта, и применяется для решения реальных практических задач реальными способами и инструментами. Теоретизировать о нём на примере воображаемых программ или воображаемых задач совершенно бессмысленно.

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

Или вы вообще скажите что на "юникс вей" можно "вляпаться" или "слететь с него" сам того не зная?

"Их нет" и "Вы их не видите" -- это разные вещи. У меня такое впечатление и складывается, что не в состоянии "увидеть", т.е. оценить те аргументы, которые приводятся многими участниками.

Возможно они достаточные для вас. Для меня нет. Ну или ткните меня носом в конкретное опровержение весомое по вашему.

Почему я должен больше верить вашему опыту чем своему?

[Voral]

Тот пример я отмёл без обсуждения по причине его чистой воображаемости.

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

Вы можете утверждать, что знаете абсолютно все задачи решаемые при помощи компьютера?
Если нет, то давайте прекратим не относящеся к теме обсуждение: "возможно это или нет".

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

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

[drBatty]

а что вам не нравится bzip2|tar?

Очень уж геморройно с т.з. пользователя. tar читает ФС сам, воткнуть туда bzip2 — нетривиально.

я так не считаю:
tar|bzip2 - типичный UNIX-Way
вообще без потоков нет никакого юнихвэя (может быть - пока нет)
а если я в состоянии понять и использовать tar|bzip2 - почему не могу наоборот?
к тому-же, я юзер tar'а, юзер bzip2, юзер конструкции tar|bzip2, причём тут программер?
а tar -cj - всего-лишь удобный способ записи tar|bzip2.

[drBatty]

1)На мой взгляд, ты смешиваешь две большие разницы: tar вызывает другие программы для смежных задач (ключевое слово -- "смежных").
2)Кроме того, tar cj это совсем не аналог tar c | bzip2: во втором случае получаем сжатый архив, в первом -- архив сжатых файлов (в терминологии rar это называется solid archive (не помню, как по-русски) и обычным архивом соответственно). Если об этом не забывать, то настоящий аналог tar cj с помощью конвейеров не так просто реализовать; если вообще возможно без временных файлов.

1) о том я и писал
2) разве? тогда bzip2|tar
будет архив сжатых файлов.
bzip2 * сделает все файлы сжатыми, а tar упакует в один

Казалось бы, tar + gzip подходят идеально? Ан нет. В процессе работы нередки ситуации, когда нужно подправить один или два файла внутри контейнера. Именно внутри; распаковывать и заново паковать весь контейнер -- не вариант, т.к. общий объём файлов в нём может превышать размер редактируемого файла на несколько порядков. Вот мы и упёрлись вограничение tar-а: он не умеет обновлять файлы в сжатом архиве

умеет.

Вы, видимо, не совсем верно поняли. На мой взгляд, речь шла в том числе и о коммерческих unix-ах, таких как HP-UX или IRIX. Ни к GNU, ни к Linux они вообще никакого отношения не имеют.

но зато напрямую связаны с UNIX-Way - они его часто нарушают.

[watashiwa_daredeska]

а если я в состоянии понять и использовать tar|bzip2 - почему не могу наоборот?

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

[drBatty]

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

cd dir; tar -cf *.bz2
так будет работать?

[watashiwa_daredeska]

cd dir; tar -cf *.bz2
так будет работать?

Нет. Я хочу не только *.bz2 в архив ведь класть, но и *.txt, *.odt, *.cpp и т.п.

[t.t]

мне неизвестен ни один "комбайн имени звездатой кнопки", который можно было бы использовать таким образом, как Вы написали. Более того -- я подозреваю, что такого нет вообще. Если я неправ, приведите конкретный пример.

aptitude
Вполне себе комбайн, даже «сапёр» встроен

По сапёру согласен. Но его туда ради смеха добавили. Кроме сапёра aptitude решает ровно одну задачу: управление пакетной системой -- и решает её более чем хорошо. В чём его "комбайновость"?

Voral, по сути отвечать не буду, как и говорил. Одно только не могу оставить без комментариев:

Хорошая у вас позиция: "Я с такими случаями не сталкивался, значит такого быть не может...".

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

Почему я должен больше верить вашему опыту чем своему?

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

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

Ещё раз попрошу не приписывать мне того, чего я не говорил. Ваш пример вполне реалистичен. Но он не относится к теме.

[Voral]

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

ok. На подстанцию я вас свозить не могу.

[VladimirP]

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

А чего тут сложного?

Код: Выделить всё

ls dir | xargs bzip2 -v9
tar cvf dir.bz2.tar dir/

[Portnov]

А вообще, интересно.
Сколько принципов нужно соблюсти, чтобы считалось по Unix-way?
И сколько принцпов нужно нарушить, чтобы считалось "не Unix-way?"

Вы близки к просветлению :)

Про сам unix-way.

1. Это не есть чеклист из N принципов, обязательных к соблюдению. Это больше похоже на разновидность дзена: набор практик, которые оказываются полезными во многих ситуациях. Поэтому говорить, что "вот у вас нарушен принцип #25, поэтому это не юникс-вей" нельзя.

2. К unix-way относятся не программы, а практики. Говорить, что "программа X - это юникс-вей" - бессмысленно. Например, можно представить использование coreutils не-юниксвейным способом. Типа, запись cp file1 /dest/dir; cp file2 /dest/dir; ... вместо простого cp * /dest/dir - противоречит юниксвею, это низачем не нужное усложнение простой команды. Можно и другие примеры придумать. А некоторые программы (openoffice, например) "на первый взгляд" выглядят противоречащими духу юниксвея, но при желании их можно вполне юниксвейно использовать (у openoffice есть headless режим, благодаря которому его можно использовать в скриптах). Другое дело, что некоторые программы (coreutils) гораздо удобнее использовать в духе юниксвея, чем другие (openoffice).

3. Вообще, формального определения вида "практика X относится к unix-way, если ..." быть не может. Unix-way - это исторически складывающийся набор практик. Любой исторически складывающийся набор практик не поддаётся формализации.

4. Unix-way - это именно way, путь, способ движения. Т.е. бессмысленно говорить про юниксвей для решения одной конкретной задачи ("вот есть конкретная железка, с неё надо снять показания и положить их в конкретное место"). Разговоры о way становятся осмысленными в применении к сериям, классам задач ("сбор показаний с железок определённого типа"; "сжатие файлов"; "редактирование текстов" итп). Потому что только в рамках целой серии задач возможно какое-то движение (скажем, переход от набора последовательных команд к одной команде с несколькими пайпами, а от неё - к скрипту-однострочнику).

[watashiwa_daredeska]

А чего тут сложного?

Разжать обратно забыл и восстановить mtime, ctime файлов. После tar c | bzip2 файлы остаются-таки нетронутыми.

[watashiwa_daredeska]

ls dir | xargs bzip2 -v9

А как же вложенные каталоги?