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

[Hephaestus]

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

Это и так известно. Никто и не спорил.

Но человек, который использует такую программу ГОРАЗДО ближе к Unux-way, чем тот, кто всю жизнь пользуется комбайнами и на каждую задачу ищет новый комбайн. И, самое главное, даже не знает, что бывает по-другому.

[Hephaestus]

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

1. Как вариант решения это прикрутить такую функцию в прогу работающую с этой базой данных. Но это не юникс вей - еще одна функция в
огромный комбайн. Да надо компилировать, обновлять.... и т.д. и т.п. А может мы и не разработчики вовсе и исходников нет.
2. Написать свою прогу. Цепляющуюся к этой базе, формирующую файл, архивирующую, отправляющую ну и попутно готовящую кофе...... Это тоже не юникс вей.
3. Юникс Вей. Причем один из вариантов решения.
у нас есть готовые утилиты: для общения с базой (для firebird - isql), возможно есть смысл обработать вывод grep'ом, сжать.... хм. сжать нам нужен rar-архив - заморачиваться нет смысла и берем "комбайн" рар..... Ну и отправляем почту sendmail.... Оформляем все это, например, скриптом.

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

УВЫ! Unix-way здесь даже рядом не пробегал.
Сидя под оффтопиком накрутить один комбайн на другой и заявлять, что это Unix-way...
Нескромно.
Voral , Вы не обижайтесь Это я так, сгоряча. Размечтался о мёде на тему "Чего хочут вышестоящие".
На самом деле пример Ваш вполне себе неплох. Особенно если rar - какая-нибудь урезанная версия, которая "только сжимает". Иначе это не Unix-way. Ибо присутствует комбайн. (Почему один комбайн - допустимо, а четыре комбайна - нет?).

Например, взять MS Word2007, в нем сгенерировать из документа HTML-страницу, и открыть ее в IE7.
Word выполняет только одну задачу - генерация HTML-страницы.
IE7 выполняет только одну задачу - просмотр HTML-страницы.
Команды можно оформить в скрипт (bat-файл).
Казалось бы - чем не Unix-way?
Однако, что-то здесь не сходится, не так ли?

[diesel]

Voral , Вы не обижайтесь Это я так, сгоряча. Размечтался о мёде на тему "Чего хочут вышестоящие".
На самом деле пример Ваш вполне себе неплох. Особенно если rar - какая-нибудь урезанная версия, которая "только сжимает". Иначе это не Unix-way. Ибо присутствует комбайн. (Почему один комбайн - допустимо, а четыре комбайна - нет?).

хотите пример классической unix-утилиты, которая в принципе умеет делать две вещи, и этим часто пользуются? А еще пользуются сочетанием этой утилиты с другой, не менее классической, при этом первая в этом случае делает только то что она умеет делать хорошо, оставляя вторую часть действа второй утилите

sort -u
sort | unic -c | sort -n

первый случай можно рассматривать как "комбайн": это sort | uniq.

"Умеет не только сжимать, но еще и по директориям бегает, и потому это не unix-way" - проблема ИМХО надуманная. Консольной реализацией rar'а под Linux'ом не пользовался, пользовался unrar'ом. unrar требованию "делает одну вещь" соответствует, делать он умеет действительно одну вещь - разжимает. Но при этом это утилита выглядит пришельцем в unix-мире, и использование ее в unix-стиле проблематично. Почему?
- насколько я понимаю не работает с stdin/stdout, cat file.rar | unrar > unpacked сделать нельзя
- "предсказуемость" ключей вызова. логично предположить что скажем программа которая распаковывает rar-архив будет работать примерно так же как программа которая распаковывает bzip2, например. то есть unrar filename.rar и в текущей директории мы получим результат распаковки. Но это не так: вы должны в обязательном порядке указать как именно мы хотим распаковать, опять же в не очень трацдионном формате: unrar x filename.rar, при этом еще есть ряд ключей которые как обычно используются с "-". В действительно из возможных вариантов распаковки в однобуквенных недоопциях собственно распаковки касаются две: x и е, первая просто распаковывает, сохраняя структуру директорий, вторая - выплевывает все файлы в одном месте не заботясь о структуре. Кому настолько часто необходима вторая, и почему нельзя было сделать первую опцию - опцией по умолчанию: "делать это если не указанно другого" не понятно.
- по-умолчанию оно слишком много "говорит", в стиле unix - дополнительная опция "показывай что ты делаешь в данный момент", возможно не одна, а не "заткнись".

7z мне кстати тоже не сильно нравится из-за несколько извращенного подхода к CLI - опциям, чего только стоит:

If you want to send files and directories (not the owner of file) to others Unix/MacOS/Windows users, you can use the 7-zip format.

example : 7za a directory.7z directory

Do not use "-r" because this flag does not do what you think.

или

7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on archive.7z dir1
adds all files from directory "dir1" to archive archive.7z using "ultra settings"

[Hephaestus]

первый случай можно рассматривать как "комбайн": это sort | uniq.

sort | uniq - это как раз Unix-way, поскольку "комбайн", так сказать, самодельный. Вот если бы создали утилиту SortUniq, которая объединяет функционал обеих - было бы совсем другое дело.

"Умеет не только сжимать, но еще и по директориям бегает, и потому это не unix-way" - проблема ИМХО надуманная.

Не такая уж надуманная. Если здесь

сжать нам нужен rar-архив - заморачиваться нет смысла и берем "комбайн" рар.....

подразумевается именно "комбайн", т.е. сжимает, шифрует, лечит, по дискам бегает... Это уже не Unix-way. Ибо тогда действительно можно взять два-три комбайна и использовать их в связке. (MS Word2007+IE7 - создание и просмотр HTML страницы из произвольного документа). Но будет ли это Unix-way? Очевидно, нет.

[Voral]

Но человек, который использует такую программу ГОРАЗДО ближе к Unux-way, чем тот, кто всю жизнь пользуется комбайнами и на каждую задачу ищет новый комбайн. И, самое главное, даже не знает, что бывает по-другому.

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

УВЫ! Unix-way здесь даже рядом не пробегал.
Сидя под оффтопиком накрутить один комбайн на другой и заявлять, что это Unix-way...
Нескромно.

Поясните какой пункт философии юникс я нарушаю используя комбайн для выполнения только дной конкретной функции?

[watashiwa_daredeska]

Вот если бы создали утилиту SortUniq, которая объединяет функционал обеих - было бы совсем другое дело.

Так diesel про это и говорит. sort -u = sort|uniq

"Умеет не только сжимать, но еще и по директориям бегает, и потому это не unix-way" - проблема ИМХО надуманная.

Не надуманная. Я сам лично сталкивался с задачей «запаковать только файлы, отвечающие определенным критериям». Можно использовать find|cpio, у tar есть опции, которые позволяют find|tar.

tar, конечно, комбайн, формально: и по каталогам сам бегает, и сжимать-разжимать умеет, ... Но всё это просто довески к хорошо выполняемой основной функции, которые можно отключить. Теперь попробуйте сделать архив rar или 7z из всех файлов, скажем, младше недели и сразу станет понятно, что rar и 7z проектировали ни разу не в стиле Unix, что, однако, не мешает пользоваться ими в этом стиле, когда они подходят.

[Voral]

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


МСВорд для создания хтмл совсем не удачный пример. Т.к.:
1. вы его в данном случае используете как комбайн: в нем и текст с кодом набираете и верстаете, и "генерирует" он у вас не только html но еще и css
2. Я еще не встречал программы хуже справляющейся с задачей "генерации html"

tar, конечно, комбайн, формально: и по каталогам сам бегает, и сжимать-разжимать умеет, ... Но всё это просто довески к хорошо выполняемой основной функции, которые можно отключить. Теперь попробуйте сделать архив rar или 7z из всех файлов, скажем, младше недели и сразу станет понятно, что rar и 7z проектировали ни разу не в стиле Unix, что, однако, не мешает пользоваться ими в этом стиле, когда они подходят.

+1
вот я так воспринимю

[Hephaestus]

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

Вещи-то разные, но беда в том, что ищут именно комбайны. (много функций - крутая прога).

Поясните какой пункт философии юникс я нарушаю используя комбайн для выполнения только дной конкретной функции?

Цитирую:

1. Маленькое прекрасно.
2. Пусть каждая программа делает одну вещь, но хорошо.
3. Собирайте прототип как можно раньше.
4. Предпочитайте переносимость эффективности.
5. Храните данные в простых текстовых файлах.
6. Используйте программные рычаги для достижения цели.
7. Используйте сценарии командной строки для улучшения функционала и переносимости.
8. Избегайте связывающего программу (captive) пользовательского интерфейса.
9. Делайте каждую программу «фильтром».

Из процитированных принципов, как минимум, первые два. В противном случае мой пример с MS Word2007 и IE7 - это тоже Unix-way, Потому что каждую из этих программ я использую для выполнения только одной функции (мне плевать, что эти программы ещё чего-то там делают - я-то их использую только для одной функции). И вообще, возьмите 5 комбайнов и от каждого по одной функции. Unix-way будет? Ничего подобного. В винде таких примеров куча. Когда ставят какой-нибудь здоровенную Nero 8 только для того, чтобы раз в полгода диск записать.

[Voral]

Поясните какой пункт философии юникс я нарушаю используя комбайн для выполнения только дной конкретной функции?

Цитирую:

1. Маленькое прекрасно.
2. Пусть каждая программа делает одну вещь, но хорошо.

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

И вообще, возьмите 5 комбайнов и от каждого по одной функции. Unix-way будет? Ничего подобного.

Я понимаю вашу позицию, но я воспринимаю это по другому.
Т.е. если взять хоть десяток комбайнов. Каждый из которых будет в вашем алгоритме выполнять очень конкретную функцию (при этом выбран этот комбайн будет именно за качество выполнения). То все вполне можно сделать юникс вейно..... Есть только одно но:
1. Я не представляю задач где есть смысл связывать несколько 5 навороченных комбайнов.
2. Как правило действительно большинству комбайнов легко находится простая замена делающая то что нужно качественно
3. Комбайн не равно плохо сделанная программа. Но в комбайне больше вероятность появления багов, и более плохих алгоритмов.

Как тут уже заметили tar тоже можно притянуть к понятию комбайн. (только давайте не будем развивать это направление беседы - оно здесь уже было).

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

[Hephaestus]

Я понимаю вашу позицию, но я воспринимаю это по другому.

Да, мы действительно понимаем по-разному.
Моё понимание - программа выполняет хорошо одну задачу. Всегда. Т.е. никаких других задач программа не умеет в принципе.
Это реализация Unix-way с позиции разработки, т.е. создания программы.

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

И по-видимому мы оба правы.
Обе точки зрения относятся к Unix-way.

ЗЫ Я в процессе написания этих постов сам глубже вникаю в вопрос.

[t.t]

Так в чём смешение понятий, если "философия Unix" и есть один из переводов термина unix-way?

Вот цитата из самого первого поста (точнее весь он полностью)

Предлагается обсудить вопрос - кто такой типичный пользователь Linux (Free- и прочей BSD). Или, иными словами, кому, зачем и на кой нужен Linux

Сочетание этих слов, заголовка и под заголовка я понял приблизительно как: "кто, зачем и почему преходит на использование Линкс (и т.п.) вместо Виндус, Мак, ОС/2, DOS и т.п.)". Правда только сам alv может сказать, что же конкретно он понимал под вопросом.

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

Вопрос поставлен некорректно. Unix-way - это путь. Т.е. не ограничивается решением одной задачи. Невозможно задачу А решать по Unix-way, а задачу B по Windows-way. Если человек одну задачу решает по принципам Unix-way, а для следующей начинает искать "звездатый комбайн", то он не идёт по Unix-way. И по Windows-way он тоже не идёт. Он просто мечется между разными подходами к решению задач. И всякий раз выбирает иной подход. У него, в данном случае, нет определённого пути.

Вот именно. (: Именно это я пытаюсь донести до ув. Voral касаемо его высказываний в этой теме уже не помню даже сколько времени.

[t.t]

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

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

Более того, вполне может сложиться ситуация когда и рар можно использовать в полном соответствии с юниксвей. Пример надо?

Давайте пример. Из него станет лучше видно, что именно Вы не понимаете.

[t.t]

надо.

Уже. С отпракой данных в другую организацию.

У меня постоянно возникает ощущение, что Вы издеваетесь. Или Вы действительно не видите разницы между задачами "закрутить шуруп" и "закрутить шуруп шуруповёртом марки BOSH"?

[t.t]

Я понимаю вашу позицию, но я воспринимаю это по другому.

Да, мы действительно понимаем по-разному.
Моё понимание - программа выполняет хорошо одну задачу. Всегда. Т.е. никаких других задач программа не умеет в принципе.
Это реализация Unix-way с позиции разработки, т.е. создания программы.

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

И по-видимому мы оба правы.
Обе точки зрения относятся к Unix-way.

Интересная коллизия наблюдается. Двадцать страниц назад Voral доказывал нам, что unix-way вообще только разработчикам (программистам) и нужен. Теперь, выходит, переметнулся в "пользовательский" лагерь?..

ЗЫ Я в процессе написания этих постов сам глубже вникаю в вопрос.

Значит, есть всё-таки польза от такого развития темы. (:

[diesel]

"Умеет не только сжимать, но еще и по директориям бегает, и потому это не unix-way" - проблема ИМХО надуманная.

Не надуманная. Я сам лично сталкивался с задачей «запаковать только файлы, отвечающие определенным критериям». Можно использовать find|cpio, у tar есть опции, которые позволяют find|tar.

не уверен что невозможность использовать rar таким же образом - это прямое следствие комбайновости. То есть то что ожидается от программы которая умеет жать, это: find | tar | rar по аналогии с тем что здесь неоднократно проскакивало для tar | bzip или tar | gzip. 7z в такой цепочке возможен, tar.7z делают, правда не без дополнительных мучений по поиску нужной опции. Проблема не в том что эти утилиты умеют больше чем просто сжимать, проблема в том что:

rar и 7z проектировали ни разу не в стиле Unix

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

[diesel]

Из процитированных принципов, как минимум, первые два. В противном случае мой пример с MS Word2007 и IE7 - это тоже Unix-way, Потому что каждую из этих программ я использую для выполнения только одной функции (мне плевать, что эти программы ещё чего-то там делают - я-то их использую только для одной функции).

в принципе, ваш пример с MS Word и IE7 не является примером unix-way, но не потому что эти программы комбайны, и умеют делать много чего. Здесь вопрос скорее к интерефейсу взаимодействия с внешнем миром.
msword.exe | ie7.exe
так нельзя, так:
msword.exe | sed ..| grep..| ie7.exe
тем более
тем более нельзя подставить вместо msword.exe, скажем vim, или cat. хотя тот же vim можно использовать в pipe'ах, погуглите если интересно примеры посмотреть. То что в ворде есть куча всего, и это еще тот комбайн, -само по себе не проблема. А вот то что взаимодействие с другими программами возможно либо из-под самого ворда, либо через уже созданный и сохраненный документ - вот это уже проблема.

И вообще, возьмите 5 комбайнов и от каждого по одной функции. Unix-way будет? Ничего подобного. В винде таких примеров куча.

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

[Hephaestus]

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

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

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

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

[drBatty]

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

У UNIX-Way есть ещё одно важное для меня преимущество: мне не нужно много разбираться в разных программах (обычный ужас бывшего виндоюзера перед сотнями утилит), дело в том, что они все ОДИНАКОВЫЕ. Разобравшись с регулярными выражениями find -regex я автоматом становлюсь Гуру по утилите grep, и уже почти всё знаю про sed и ещё множество этих сотен команд. В Windows-Way всё не так: каждой фишке я должен обучаться заново. Даже если я знаю как реализована конкретная фича в программе X, это практически ничего мне не даст в программе Y. В виндовс конечно есть общие примеры, но они касаются только самой виндовс и её оконного менеджера. Например - проводник, который использует общие диалоги с другими программами для открытия файлов. Вот только всё это замкнуто в тесном мире MS, что заставляет виндо-программистов изобретать велосипеды, такие-же, только фиолетовые и с 4мя колёсами, ну и виндоюзерам приходится каждый раз (иногда даже с переходом на новую версию) учится на них кататься.

По поводу: сколько принципов нужно соблюсти?
ИМХО все. Просто не нужно их формулировать столь жёстко: например tar выполняет всего ОДНУ задачу, хотя и может привлекать другие утилиты/библиотеки для помощи (ключи -j и -z), или cp --backup: конечно бекапы и копирование разные вещи, но если смотреть на копирование как на часть задачи изготовления бекапов...
Я уж не говорю про sed, на которой гуру писали даже калькуляторы! (см. sed info)

[Hephaestus]

У UNIX-Way есть ещё одно важное для меня преимущество: мне не нужно много разбираться в разных программах (обычный ужас бывшего виндоюзера перед сотнями утилит), дело в том, что они все ОДИНАКОВЫЕ. Разобравшись с регулярными выражениями find -regex я автоматом становлюсь Гуру по утилите grep, и уже почти всё знаю про sed и ещё множество этих сотен команд. В Windows-Way всё не так: каждой фишке я должен обучаться заново. Даже если я знаю как реализована конкретная фича в программе X, это практически ничего мне не даст в программе Y. В виндовс конечно есть общие примеры, но они касаются только самой виндовс и её оконного менеджера. Например - проводник, который использует общие диалоги с другими программами для открытия файлов. Вот только всё это замкнуто в тесном мире MS, что заставляет виндо-программистов изобретать велосипеды, такие-же, только фиолетовые и с 4мя колёсами, ну и виндоюзерам приходится каждый раз (иногда даже с переходом на новую версию) учится на них кататься.

ППКС

[watashiwa_daredeska]

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

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

У UNIX-Way есть ещё одно важное для меня преимущество: мне не нужно много разбираться в разных программах (обычный ужас бывшего виндоюзера перед сотнями утилит), дело в том, что они все ОДИНАКОВЫЕ.

Это не Unix-way, это достаточно общий принцип minimal surprise. Программы для MacOS X его также соблюдают.

В Windows-Way всё не так: каждой фишке я должен обучаться заново.

Ну, некоторое количество общих принципов всё же соблюдается — главное меню сверху, меню «Файл», «Справка», стандартные диалоги, кнопка приложения в task bar или tray и т.п. Точно также есть некоторое количество общих принципов, используемых утилитами unix — параметры в стиле GNU (заметьте, GNU, а не Unix), регулярные выражения, и т.п. А исключения бывают везде.

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

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

Проблема совсем в другом — в пределе возможностей. Я сейчас уже не найду ссылок, но несколько лет назад мимо пробегал отчет преподавателя компьютерной грамотности (буржуйского какого-то). Он сравнивал две своих группы учеников (обе учились с полного нуля) — одну Windows, одну Linux. Не просто Linux с GNOME/KDE и пр., а командная строка сотоварищи. Поначалу группа Windows опережала группу Linux по возможностям, которые могли получить от компьютера, но довольно быстро Windows-группа уперлась в потолок, в то время как Linux-группа продолжала наращивать доступные ей возможности и вскоре Linux-группа далеко обскакала Windows-группу.

[watashiwa_daredeska]

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

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

[Ali1]

Вообще же, Unix — частный случай компонентной среды.

Простой компонентной среды.

[Voral]

Интересная коллизия наблюдается. Двадцать страниц назад Voral доказывал нам, что unix-way вообще только разработчикам (программистам) и нужен. Теперь, выходит, переметнулся в "пользовательский" лагерь?..

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

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

Хорошо, в принципе пример с архиватором натянутый. Давайте так. Вот мне например приходилось писать под винду достаточно специфичный софт - работающий в паре с некими железяками. Я тогда еще полностью виндо-программист, требования от заказчика таковы, что нужен именно комбайн и даже со "звездатой" кнопкой. При этом факт остается: Только моя программа работает с данной железкой и делает это превосходно. И вот я перешел на линукс. Полностью философией не проникся и просто добавляю в свой софт, например: по ключу отключение не нужных фенечек типа гуя, и всевозможных удобств для взаимодействия между программ в духе Линукса. И вот мой "комбайн" можно уже заряжать, в нечто типа mycomb | sed .... | ......
И на мой взгялд в данном случае:
1. Я как программист написавший данны комбайн не "на Unix Way"
2. Пользователь построивший свее решение примерно как в строке выше - почему нет? На мой взгляд все вполне ок.


Кстати, если ВЫ не заметили. Я ни чего сейчас не доказываю. Я лишь показал, что все разногласия из-за разной трактовки основных понятий. И тут же на меня "накинулись"

Тем не менее я не нашел ни одного доказательства, что моя позиция неверна и ошибочна (в прочем как и нет доказательств, что она абсолютно верная)

Значит, есть всё-таки польза от такого развития темы. (:

А в таких развитиях всегда есть польза.... Хуже когда идет сплошное поддакивание.

[Voral]

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

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

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

[drBatty]

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

возможно. если она будет выполнять "одну задачу". В вашем случае - СДЕЛАЙТЕ МНЕ ХОРОШО!
ИМХО я как раз такое часто и пишу - довольно сложный скрипт, который выполняет множество вещей, причём многие - самостоятельно, например sed-скриптом или shell-скриптом. Но это для НЕГО много задач, для МЕНЯ задача одна - например быстро свернуть систему, пока не пришла ЧК.

Конечно, если ваш скрипт (утилита) будет выполнять кучу действий ДЛЯ ВАС (как её пользователя) - это НЕ Unix-Way.

ИМХО.

У UNIX-Way есть ещё одно важное для меня преимущество: мне не нужно много разбираться в разных программах (обычный ужас бывшего виндоюзера перед сотнями утилит), дело в том, что они все ОДИНАКОВЫЕ.

Это не Unix-way, это достаточно общий принцип minimal surprise. Программы для MacOS X его также соблюдают.

ИМХО - недостаточно хорошо соблюдают.
да и вообще, причём тут маки? там тоже многое сделано как UNIX-Way.

Ну, некоторое количество общих принципов всё же соблюдается

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

главное меню сверху, меню «Файл», «Справка», стандартные диалоги, кнопка приложения в task bar или tray и т.п.

угу. помнится в MS Word я не мог найти кнопку печать. при том, что там по дефолту отрубили хоткей CTRL+P. ЗАКОПАЛ-БЫ!!! (потом откопал-***-и обратно закопал. К счастью я этим УГ не пользуюсь уже много лет).

Точно также есть некоторое количество общих принципов, используемых утилитами unix — параметры в стиле GNU (заметьте, GNU, а не Unix)

нет. именно UNIX. в большинстве утилит GNU опции прилагаются как дополнение (cp, mv, tar, find, grep, sed...)
Заметьте: это фундаментальные утилиты - без них вообще нечего делать в *NIX.

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

Ага. ОпИсаны. Я-бы грохнул писателей, которые пишут MSDN!. Вы это УГ читали? Фтопку!!!
Кроме того, это касается только очень немногих вещей (кроме упомянутого вами диалога есть ещё аналог xmessage, как там у них, вроде MessageBoxA, ну и в общем-то всё...). Остальное извольте писать сами.

Проблема совсем в другом — в пределе возможностей. Я сейчас уже не найду ссылок, но несколько лет назад мимо пробегал отчет преподавателя компьютерной грамотности (буржуйского какого-то). Он сравнивал две своих группы учеников (обе учились с полного нуля) — одну Windows, одну Linux. Не просто Linux с GNOME/KDE и пр., а командная строка сотоварищи. Поначалу группа Windows опережала группу Linux по возможностям, которые могли получить от компьютера, но довольно быстро Windows-группа уперлась в потолок, в то время как Linux-группа продолжала наращивать доступные ей возможности и вскоре Linux-группа далеко обскакала Windows-группу.

я не думаю, что это из-за UNIX-Way.
это ограниченность САМОЙ венды: в ней просто ничего не сделать выше некоторого порога. Ну так она проектировалась...

[drBatty]

Однако в рар-формат скорее всего лучше сжимает именно сам рар.

небольшое уточнение:
На практике применяются 3 алгоритма сжатия:
1) LZ77/78 (zip, gzip, rar...)
2) BWT (bzip, lzma...)
3) PPM (rar...)
У каждого алгоритма есть свои достоинства и недостатки.
Формата "rar" - НЕ существует: как написано к документации этого архиватора, он сжимает либо как zip, либо с помощью PPMD, либо вообще никак. Существует множество сжимаетелей, среди которых есть и более лучшие. Если есть желание, можно написать скрипт, который работает в точности как рар - жмёт парой методов, и сохраняет лучший результат. Другое дело, что это никому особо и не надо (а может и надо, посмотрите в гугле).
да, и вот ещё:
Ссылки на архиваторы и вообще про это:
таблица архиваторов: http://compression.ru/download/arc-ru.htm
FTP с архиваторами: ftp://ftp.elf.stuba.sk/pub/pc/pack/
русский сайт про сжатие: http://www.compression.ru/

[watashiwa_daredeska]

возможно. если она будет выполнять "одну задачу". В вашем случае - СДЕЛАЙТЕ МНЕ ХОРОШО!

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

Конечно, если ваш скрипт (утилита) будет выполнять кучу действий ДЛЯ ВАС (как её пользователя) - это НЕ Unix-Way.

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

[Voral]

небольшое уточнение:

Спасибо за уточнение.

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

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

[watashiwa_daredeska]

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

Недостаточно для чего?

ИМХО - недостаточно хорошо соблюдают.

Маководам нравится.

да и вообще, причём тут маки? там тоже многое сделано как UNIX-Way.

Маки тут при том, что принцип minimal surprise соблюдают далеко не только те инструменты, которые сделаны в стиле Unix-way. Кстати, unix-инструменты в Маке, как раз, это очень большой surprise, начиная с fs layout.

[watashiwa_daredeska]

помнится в MS Word я не мог найти кнопку печать.

Ну, знаете, я вот в некоторых flavor unix'а с которыми мне довелось работать тоже не мог найти многих ключиков grep, sed и т.п. Апофеозом было нахождение того, что то, что я привык считать awk'ом, по POSIX называется nawk и весьма отличается от awk. В линуксе это одно и то же, а вот кое-где нет. И что это доказывает?

именно UNIX. в большинстве утилит GNU опции прилагаются как дополнение

Ну да, ибо есть что дополнять — POSIX там, SUS, ... В винде дополнять нечего. Но суть от этого не меняется, кроме писаных стандартов, есть стандарты де-факто. GNU-style ключи командной строки были именно таким де-факто. ЕМНИП, с крайним POSIX они стали де-юре.

Ага. ОпИсаны. Я-бы грохнул писателей, которые пишут MSDN!. Вы это УГ читали? Фтопку!!!

Читал. Давно правда. Возможно, тогда и MSDN был лучше, и трава зеленее, и девки моложе.

Аргументация, конечно, потрясная, да.

я не думаю, что это из-за UNIX-Way.
это ограниченность САМОЙ венды

А что такое САМА винда? Как известно, Microsoft практически ничего не изобрела. Уж GUI и концепцию desktop она не изобретала, это точно. Точно те же идеи лежат в основе GNOME, KDE и прочих DE. Вы считаете, что они принципиально богаче возможностями сами по себе (без призывания на помощь shell/grep/sed/awk)?