Все, вроде, хорошо и даже интересно. Замечания следующие: 1. Упомянуть про bash и забыть про sh - это стильно! Такой вот UNIX-way. Я бы предложил не позориться и рассазать про sh, также упомянуть про csh , ksh, а уже потом про bash, tcsh и прочие доделки. 2. То, что вам лично не нравиться perl еще не повод давать рекомендации не изучать его. Perl был и остается наиболее эффективным средством решения довольно широкого круга задач.

Называть elisp лиспом - оскорблять лисп. А уж упоминать AI в одном предложении со словом лисп - преступление, заслуживающие расстрела (злостное охмурение новичков, вроде меня).

Ну, во-первых в большинстве дистров GNUS всё-таки в виде байткода идёт, а не скриптом.

Во-вторых, помимо emacs и vi(m) есть туева хуча (не менее 400) других текстовых редакторов (в смысле их вовсе не два, как видно некоторым уважаемым win-программистам).

Отдельной темой можно сделать трубы(pipe). Если не ошибаюсь - в UNIX они и возникли. И без них все эти awk, grep и sed бесполезны, равно как и текстовые файлы.

Ещё про потоки: gcc - хороший тому пример. Сама по себе gcc - сугубо управляющая программа. Она вызывает препроцессор, анализатор, генератор кода, ассемблер и наладчик связей (linker). Причём первые три проги едят и испускают читаемый текст. И текст этот между ними ходит по трубам (если gcc -pipe запускать - точно по трубам). Как следствие - можно отловить любую фазу компиляции (c++ программа с раскрытыми #include или ассемблерный листинг программы без дезассемблирования)

А "всё есть файл" проще пояснить на примере 'dd if=/dev/hda of=bootect size=512 count=1' для сохранения boot сектора или 'cat /dev/fd0 > win98BootDisk.img' для снятия образов загрузочных дискет.

Ещё про текстовые файлы: классический пример - /etc/passwd. На нём же пояснить формат DSV(delimiter separated value) и экранирование разделителей с помощью backslash.

И последнее - emacs так же иожно назвать и средой разработки из-за интеграции с make и gdb.

p.s. Анонимов давить, удалять и не читать.

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

По существу - стоит сказать, что начинать надо с чтения man man (как это ни пародоксально), мне это позволило мне в свое время найти команду du ;-). А вообще, просто по man'ам овладеть юнихом трудно. Поставь в конце список литературы и на первом месте Эви Немет - тем более что она регулярно переиздается и дополняется.

Критика: меня просто поразило, что ты не разобрался с регулярными выражениями "несмотря на написанные мною десятки тысяч строк кода на этом [perl] языке". Поэтому ты его и не рекомендуешь, что не использовал самого главного. Perl это очень даже юних-way. Cобственно, он не хуже и не лучше чем упомянутые тобой Python и Tcl. По этому поводу можно много флеймить, но мастер любого из этих языков решит поставленную задачу за примерно одинаковое время, а те кто будет сейчас орать что XXX - suxx, а YYY - rulez, просто лучше знают YYY, или не знают XXX вообще.

Поэтому попроси написать эти абзацы тех, кто _знает_ Perl и регулярные выражения.

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

> Ну, во-первых в большинстве дистров GNUS всё-таки в виде байткода идёт, а не скриптом.

А-а-а-а-а ...

> Во-вторых, помимо emacs и vi(m) есть туева хуча (не менее 400) других текстовых редакторов (в смысле их вовсе не два, как видно некоторым уважаемым win-программистам).

А что V.Wagner - это win-программист? (Если не ошибаюсь, "ровно два редактора" - это цитата из него). Спасибо, что открыли глаза.

> Отдельной темой можно сделать трубы(pipe). Если не ошибаюсь - в UNIX они и возникли. И без них все эти awk, grep и sed бесполезны, равно как и текстовые файлы.

Ну кто бы мог подумать?

> наладчик связей (linker).

Отлично!

> А "всё есть файл" проще пояснить на примере ...

Лучше cp /dev/zero /dev/hda

> И последнее - emacs так же иожно назвать и средой разработки из-за интеграции с make и gdb.

Низзя - он с cscope не интегрирован и перловых модулей к нему мало.

> p.s. Анонимов давить, удалять и не читать.

А кто ж вам жирным, наглым и зарегистрированным укажет на ошибки?

Видел где-то классную фразу - "Perl это мощь C, с читабельностью PostScript".

Хотелось бы видеть больше инфо о Blender (т.к. я его продвигаю всем своим знакомым 3D-шникам).

А вообще - статья грамотная - это дело хорошее. А анонимусов - давить.

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

А у меня такое нарастающее подозрение, что люди просто прочитали The Art of Unix Programming by esr (http://www.catb.org/~esr/writings/taoup/html/), переварили его и выкакали :) Всем респект :)

> Ну, во-первых в большинстве дистров GNUS всё-таки в виде байткода идёт, а не скриптом.

Смысл от этого ведь не меняется.

> Во-вторых, помимо emacs и vi(m) есть туева хуча (не менее 400) других текстовых редакторов (в смысле их вовсе не два, как видно некоторым уважаемым win-программистам).

С моей личной точки зрения другие редакторы не заслуживают упоминания в контексте UNIX-way.

> Отдельной темой можно сделать трубы(pipe). Если не ошибаюсь - в UNIX они и возникли. И без них все эти awk, grep и sed бесполезны, равно как и текстовые файлы.

Да, я об этом думаю.

> Ещё про потоки: gcc - хороший тому пример. Сама по себе gcc - сугубо управляющая программа. Она вызывает препроцессор, анализатор, генератор кода, ассемблер и наладчик связей (linker). Причём первые три проги едят и испускают читаемый текст. И текст этот между ними ходит по трубам (если gcc -pipe запускать - точно по трубам). Как следствие - можно отловить любую фазу компиляции (c++ программа с раскрытыми #include или ассемблерный листинг программы без дезассемблирования)

А вот за это напоминание очень большое спасибо.

> А "всё есть файл" проще пояснить на примере 'dd if=/dev/hda of=bootect size=512 count=1' для сохранения boot сектора или 'cat /dev/fd0 > win98BootDisk.img' для снятия образов загрузочных дискет.

Угумс.

> Ещё про текстовые файлы: классический пример - /etc/passwd. На нём же пояснить формат DSV(delimiter separated value) и экранирование разделителей с помощью backslash.

Надо добавить.

> И последнее - emacs так же иожно назвать и средой разработки из-за интеграции с make и gdb.

Верно.

> p.s. Анонимов давить, удалять и не читать.

:)

Изредка и анонимы что-нибудь умное сказать могут.

> Видел где-то классную фразу - "Perl это мощь C, с читабельностью PostScript".

Смешно. Но в отличие от Си у Perl моща таки есть. Хотя программы на нем и не читаются так хорошо, как приличные программы на forth.

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

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

Разобраться можно в любом коде, но вот цена этого удовольствия...

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

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

Не надо иметь опыт. Достаточно прочитать Perl Cookbook.

>> Во-вторых, помимо emacs и vi(m) есть туева хуча (не менее 400) других текстовых редакторов (в смысле их вовсе не два, как видно некоторым уважаемым win-программистам).

>А что V.Wagner - это win-программист? (Если не ошибаюсь, "ровно два редактора" - это цитата из него).

Ничто не мешает тебе/мне иметь свое мнение отличное от его. Тем более, что это было сказано ~4-5 лет назад, и донести он (на мой взгляд), пытался ту же мысль, как и в любой старой книге по юниху (новых я не читал, не скажу) - если твой любимый редактор не один из этих двух - то чтобы чувствовать себя комфортно, тебе придется таскать этот редактор всё время с собой. С этих пор наличие быстрого инета все изменило. Хоть Eclipse скачивай, если он тебе удобнее. И когда мне надо написать что-нибудь длиннее чем 'Hell,Wolrd' на жабе, я так и делаю.

И, кстати он упустил (самый?) старый юнихный редактор - ed. Есть еще до сих пор извращен^H^H^H^H^H^H^H^H любители и его.

> Все, вроде, хорошо и даже интересно. Замечания следующие: 1. Упомянуть про bash и забыть про sh - это стильно! Такой вот UNIX-way. Я бы предложил не позориться и рассазать про sh, также упомянуть про csh , ksh, а уже потом про bash, tcsh и прочие доделки. 2. То, что вам лично не нравиться perl еще не повод давать рекомендации не изучать его. Perl был и остается наиболее эффективным средством решения довольно широкого круга задач.

Всё-таки речь идёт о UNIX-way в контексте Linux, Поэтому как раз bash-то и есть смысл упоминать (как используемый чаще всего шелл). Упромянуть про остальные шеллы можно и нужно, с этим я согласен. Any ideas или материалы?

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

> Отдельной темой можно сделать трубы(pipe). Если не ошибаюсь - в UNIX они и возникли.

esr приводит некоторые недостатки каналов как метод IPC, в частности что они односторонние:

The major weakness of pipes is that they are unidirectional. It's not possible for a pipeline component to pass control information back up the pipe other than by terminating (in which case the previous stage will get a SIGPIPE signal on the next write). Accordingly, the protocol for passing data is simply the receiver's input format.

А так статья освежает, можно порекомендовать как легкую прелюдию к TAOUP, или же если есть проблемы прочтения последней в оригинале (я когда читал довольно часто обращался к словарю, esr очень склонен к красноречию :))

Много ли народу использует специфичные для bash возможности? Имхо, если писать под оболочку, надо не выделяться за рамки POSIX, так что если писать, то про sh, не забывая при этом сообщить про bash как про его более развитую "реализацию". Лично я бы про zsh также пару слов ввернул - очень уж интерактивно удобен.

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

> Много ли народу использует специфичные для bash возможности?

Да, к сожалению.

> Лично я бы про zsh также пару слов ввернул - очень уж интерактивно удобен.

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

> Перл же не относится к моим любимым языкам - он скорее суровая > необходимость. Мне ближе что нибудь построже, вроде python. Но - от > перла уже никуда не деться. Кстати, кривизна его, имхо, мнимая. > Просто, его надо хорошо знать, а это сложно

О чём и речь -- если он необходим, то вопрос выбора и не стоит. А если можно обойтись без него, то лучше обойтись (новичку).

И в самом деле про ед забыли. 

=== offtopic follows this line

И ещё про emacs:

program asd;

var
   i	       : iteger;
   s1, s2      : string;
   bla_bla_vla : boolean;
   f	       : array[1..100]of real;
begin
   writeln("нафига столько переменных?");
end.

когда набирал текст этой "проги":
5 раз нажал на пробел (там где должны стоять пробелы),
_ни одного_ раза не трогал TAB
и ниразу не притронулся к del/backspace.

_НА ДАННОМ КОНКРЕТНОМ ПРИМЕРЕ_ emacs гораздо круче чем vim.

По поводу анонимов: на одну идею 20 наездов + начало обсуждения.

Про "всего два редактора" - впервые вычитал в лекциях по пайтону за 
авторством Зайцева В. А. Цитата :
"В юниксах, вообще говоря, всего два редактора: vi и emacs, и каждый юниксоид, 
подчас великолепно владея одним из них, с трудом догадывается о том, как выйти 
из другого." 

"меня просто поразило, что ты не разобрался с регулярными выражениями" - ничего удивительного, чтобы понять, как работает регексп 'aaabc' =~/a+abc/ надо разобраться что такое недетерминированные конечные автоматы (кажется, или детерминированные - не понмю уже что именно в перловых регекспах юзается)... Можно, конечно, взять мастеринг регулар экспрешшнс кажись и прочитать, но дык этож еще одна книга... А вообще имхо регекспы они как дифуры. просто там знать дохрена надо в них... я вот не знаю, что сложнее, перл или c ...

>> "Можно, конечно, взять мастеринг регулар экспрешшнс кажись и прочитать, но дык этож еще одна книга..."

Достаточно будет Ахо & Ульмана :-))

PS. Я плакалъ и рыдалъ. Человек, по собственному признанию, не смогший разобраться в работе регекспов пишет статьи про "Уних-вей для праффисианалов".

Сообщаю всем интересующимся.

"Разобраться в работе NNN" (например, регекспов) и "разобраться как НАПИСАТЬ про работу NNN" - "две большие разницы".

Первое требуется для второго, но отнюдь не достаточно.

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

Если кто-то сей подвиг уже совершил, или совершить собирается, и готов предоставить результаты для свободного распространения, прошу срочно связаться со мной. Способы - на странице сборника http://ramendik.ru/freebook . На которую, впрочем, вообще всех приглашаю - отдельная новость об этом уже отправилась на модерирование.

Михаил Рамендик. Составитель сборника "Дары свободы. Свободное ПО: прошлое, настоящее, будущее". Технический писатель с пятилетним стажем (это для желающих поспорить о том, что я знаю о создании документации).

судя по имени ссылки и кодировки в которой написана статья можно сказать, что автор огромный поклонник этого самого unix way. Наверняка он вдобавок еще использует Open Office и какой-нибудь майл клиент типа sylpheed/kmail.

>Я промолчу про такой коммерческий пакет как Maya, который бесплатен для персонального использования, и на котором был сделан фильм Final Fantazy, и который отличается от модной у нас 3DStudioMax как Боинг от дельтаплана.

Да-да, промолчи пожалуйста, а то своими сравнениями ты ясно дал понять, какое отдаленное представление имеешь об этих продуктах. Maya Personal Edition под Linux нет! А если бы ты хоть раз поработал с 3ДМаксом, то заметил бы, что он сделан в не менее "классическом UNIX-стиле", чем Maya. Лучше выброси раздел "3D графика" из своей статейки - ну не выдерживает Blender сравнения с коммерческими продуктами.

:-)

Вообще глупо сравнивать коммерческий продукт с многолетней разработкой и бесплатный редактор. Но можно упомянуть, что на два с половиной мегабайта бинарника Blender уложено столько функций, что если бы он при такой-же "функциональной плотности" занимал CD (как та-же Maya) то все Maya, 3D Studio, Softimage и прочие дизайнерские пакеты сдохли бы от зависти. При том у них релизы - каждый месяц, и каждый раз что-то новое и нужное.

Согласен, там нету всего. Но то, что там есть заслуживает уважения. Я видел работы сделанные в Blender и могу сказать, некоторые их них - ничуть не хуже вещей сделанных в MAX, Maya и прочая...

Странно - начал с кирпичиков (что хорошо, ибо везде об этом написано, но как-то вскользь), а закончил быстрым обзором программного обеспечения. Причем не везде корректным.

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

Блендер, насколько я помню, сейчас кардинально меняется - его опасно куда-либо продвигать.

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

P.S. Но продукт в перспективе достойный.

А где упоминание о PHP. Большая часть инета написана именно на этом языке. Все что присуще Perl (нечитаемость кода сложный синтаксис и прочее), в PHP с этим все впорядке. И если упоминать язык для интернета, то не упомянуть о PHP, за это считаю убогой статью, написанную новичком за пятнадцать минут без логического осмысления того что написал. И не сравнивай Perl с С исли С не знаешь. Perl больше на forth похож. А С это PHP.

с ПэЖоПэ идите в сад

>С моей личной точки зрения другие редакторы не заслуживают упоминания в контексте UNIX-way.

Уж если быть до конца религиозным фанатиком то *NIX-way это ed а остальное не заслуживает и упоминания ;) (vi,emasc,pico,jed,fte,etc)

По тексту ... ImHO слегка сумбурно написано с кучей лишних "IMO" (как то про regexp и perl)последние абзацы про 3D тут вообще смотрится как нечто лишнее. Про X-ы вообще не упоимнается (хотя говорится про какуто графику с помощью TCL/Tk), про Free только заголовок, из самого текста не понять почму Free.

Про самый что ни на есть *NIX-way - терминалы, вообще ни слова про файлы - полный сумбур, ну хотя мы перечислили 6 типов файлов а то тезис "все есть файл" неискушенному читателю останется непонятен.

Тезес про "все есть текст" непонятен даже мне, что _все_ ?

И хотелось бы видеть побольше красивых примеров (пример с wc мне _красивым_ не показался - скорее неуклюжим)

Вообще уже общим местом стало критиковать Perl на нечитабельнось, но вообще imho большой вины языка тут нет - на нем вполне можно писать ясно, он искушает возможностью запихнуть в одну строку то, что можно расписать в 3 или 5 строк. Никто не заставляет так делать и в скорости исполнения выигрыша почти нет. use strict (иногда это необходимость), прокоменнтировать переменные и неясные участки, не сильно злоупотреблять переменными по умолчанию типа $_, или вообще по возможности прописывать переменные явно, использовать скобки и тд. В С и прочих языках стили кодирования не для красивости придумали, также и в Perl-е писатель вполне может подумать о читателе, тем более что готовым продуктом является не скомпилированный бинарник, а открытый текст. Писать хитро и непонятно - вроде особого литературного удовольствия и изыска, как употребление в речи аллюзий, редких слов и имен, необычных сочетаний и подтекста. Перл дает возможность писать хитрым слогом, только такое удовольствие иногда боком выходит.

КАК БЫТЬ С XML ?

лучший редактор NEDIT

лучший скрипт sh

лучший графич. пакет gimp

народ, а вот grep там и sed это конечно круто, НО !!!

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

>как быть с XML ? сейчас все даты переводят в иксмээль, и должны быть же такие же аналоги тока для иксмээля

man libxml ?

хотя XML это ни разу не *NIX-way (imho)

> Хотелось бы видеть больше инфо о Blender (т.к. я его продвигаю всем своим знакомым 3D-шникам).

В таком случае вам лучше всего написать свою статью о Blender в готовящийся сборник.

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

> Странно - начал с кирпичиков (что хорошо, ибо везде об этом написано, но как-то вскользь), а закончил быстрым обзором программного обеспечения. Причем не везде корректным.

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

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

Вообще это вариант. Дело только в том, что цель -- показ именно программ относящихся к unix-way, например openoffice в этой статье упоминаться не должен.

> Уж если быть до конца религиозным фанатиком то *NIX-way это ed а остальное не заслуживает и упоминания ;) (vi,emasc,pico,jed,fte,etc)

Моя религия -- эффективность. Если эффективным будет тыкать мышкой в ворде -- я буду тыкать мышой в ворде. Если эффективно будет программировать прокалывая дырки в перфокартках -- буду прокалывать дырки в перфокартах.

> По тексту ... ImHO слегка сумбурно написано с кучей лишних "IMO" (как то про regexp и perl)

Где, ну где вы увидели хоть какое-то IMHO про regexp'ы? Я обожаю регекспы, я постоянно применяю регеспы, и считаю их единственным что оправдывает существования перла.

> последние абзацы про 3D тут вообще смотрится как нечто лишнее. Про X-ы вообще не упоимнается (хотя говорится про какуто графику с помощью TCL/Tk), про Free только заголовок, из самого текста не понять почму Free.

Free -- потому что речь идёт именно о Linux. БОльшая часть написаного может быть применима и к коммерческим юниксам, но не всё.

Про X-ы -- надо добавить.

3D -- в идеале надо бы разъяснить получше про PovRay.

> Про самый что ни на есть *NIX-way - терминалы, вообще ни слова про файлы - полный сумбур, ну хотя мы перечислили 6 типов файлов а то тезис "все есть файл" неискушенному читателю останется непонятен.

Это было в TODO :-)

> Тезес про "все есть текст" непонятен даже мне, что _все_ ?

Посмотри описание, например, формата pbm :-) Реально сейчас экспортируется в текстовые форматы всё, кроме звука, увы.

> И хотелось бы видеть побольше красивых примеров (пример с wc мне _красивым_ не показался - скорее неуклюжим)

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

Если вы можете предолжить более красивые примеры -- you are welcome

> судя по имени ссылки и кодировки в которой написана статья можно сказать, что автор огромный поклонник этого самого unix way. Наверняка он вдобавок еще использует Open Office и какой-нибудь майл клиент типа sylpheed/kmail.

Имя ссылки выглядит именно так из-за использования wiki-движка.

Open Office я не пользуюсь, увы -- предпочитаю собственное подмножество latex'а, из которого скриптами конвертирую в html и latex.

Почтовый клиент у меня mutt + несколько perl-скриптов, делающих работу с ним терпимее. Ещё вопросы будут?

> А где упоминание о PHP. Большая часть инета написана именно на этом языке. Все что присуще Perl (нечитаемость кода сложный синтаксис и прочее), в PHP с этим все впорядке. И если упоминать язык для интернета, то не упомянуть о PHP, за это считаю убогой статью, написанную новичком за пятнадцать минут без логического осмысления того что написал. И не сравнивай Perl с С исли С не знаешь. Perl больше на forth похож. А С это PHP.

PHP никакого отношение к юникс-вею не имеет.

> Тезес про "все есть текст" непонятен даже мне, что _все_ ?

Посмотри описание, например, формата pbm :-) Реально сейчас экспортируется в текстовые форматы всё, кроме звука, увы.

Во первых это не отражено в тексте во вторых не уверен что это есть хорошо в третих в *NIX далеко не "всё есть текст" этот тезис явно лишний по крайней мере в том виде как он заявлен.

Тут недавно на Федорчука справедливо наезжали за откровенно слабую статью про FreeBSD. Но и эта не лучше! 
Тоже поверхностно и однобоко, только в сторону Линукса. Если ты пишешь про Unix-way, так и пиши про Unix-way. 
При чём здесь bash? Монстр, вся фишка которого в удобных интерактивных возможностях. 
Это здорово, я и сам его предпочитаю как интерактивную оболочку. Но ни в одном юниксе (и UNIX-like), 
кроме линукса, он не ставится в качестве оболочки по умолчанию. К тому же в статье ты говоришь в основном 
о скриптовых применениях оболочки. А в этом качестве bash никак не тянет на Unix-way т.к 99% его 
возможностей в данном случае никак не используются. Отсюда монстроидальность и тормоза. 
Unix-way - это маленький, быстрый, стандартизованный IEEE Std 1003.2 (``POSIX.2'') интерпретатор sh, 
который ты почему-то даже не упомянул но который присутствует в качестве стандартного скриптового 
интерпретатора в любой UNIX/UNIX-like ОС (увы, кроме линукса). Заодно, в качестве примера почему 
в качестве интерпретатора скриптов не следует использовать баш посмотри на простейший скриптик:
i=0
j=0
while [ ! "$i" = '1000000' ]
do
        while [ ! "$j" = '100' ]
        do
                j=$(( $j + 1 ))
        done
        i=$(( $i + 1 ))
done

Попробуем выполнить его под настоящим sh и под башем (делается на FreeBSD-5.2):
time sh ./loop.sh | grep real
real    0m34.823s

time bash ./loop.sh | grep real
real    2m3.559s

БАШ ТОРМОЗНЕЕ В 4 РАЗА! Долой башизмы-линуксизмы из скриптов! Пишите быстрые и переносимые программы!
Правда пользователям Линукса повторять это не стоит, т.к. линуксячий sh это всего хардлинк на тот же самый баш. 
Не повезло! Отсутствие свободы выбора это плохо!

2Alex_M

Абсолютный религиозный бред в стиле bash vs sh и FreeBSD vs Linux

скорость _работы_ скриптового языка это _последнее_ что от него требуется а требуется гибкость скорость _написания_

>А в этом качестве bash никак не тянет на Unix-way т.к 99% его возможностей в данном случае никак не используются.

Кто кого использует на 1 % bash унихс-вея или наоборот ? :))

А С это PHP.

Хорошо сказано.

> БАШ ТОРМОЗНЕЕ В 4 РАЗА!

Пишущие математику на шелл-языке идут лесом.

> А С это PHP. > Хорошо сказано.

Такая же попсня? ;-)

Если не упоминать OO, который действительно не unix-way как программа, но unix-way по духу (т.е. a) что его разрабатывало community b) что он является заменой ОО - чего не хватает, пишем сами), то как произвести впечатление на людей, работающих с doc (как я, например)?

unix-way с красивыми примерами?
Вот функциональный пример (а главное, полезный).
cat (программа, которая очень часто используется) для склейки файлов,
пайп в количестве одной штуки, mencoder, который позволяет работать
с потоком и работает из командной строки,
слэш как средство не писать километровые строки.
nice как средство сделать свою работу комфортной, пока программа что-то
делает.

cat /heap/dvd/*vob | nice -n 15 mencoder - -ofps 25 -ni -aid 128 \
-ovc ... \
-oac ... \
-o new.avi

или сборка имиджа под knoppix:

mkisofs -R -U -V "KNOPPIX.net filesystem" -P "KNOPPIX www.knoppix.net" \
-hide-rr-moved -cache-inodes -no-bak -pad /mnt/KNOPPIX | nice \
-5 /usr/bin/create_compressed_fs - 65536 > /heap/ready/KNOPPIX

Те же пайпы, ключи, записи в файл со стандартного потока.

Просто всех заколебало разводить зоопарк - нах десять оболочек? Ну надо тебе - возьми и собери. Это недолго.
А запускать те же скрипты для перекодировки видео или еще чего-нить - баша вполне хватает. Остальные его возможности переплюнут sh. Поэтому нах.

Т.е. у тебя система не на C написана?

Кстати, о maya. Бесплатная версия сильно порезана.