Что есть UnixWay?

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

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

пример -- убийство процесса с именем process
1) уних-вэй:
 $ kill `ps -axc | grep process | grep -v grep | cut -f 1 -d ' '`

2) vms-вэй:
 вариант a)
  $ stop process
 вариант б)
  $ show system
  [ ищем глазами процесс, потому что понятия пайпа там нету ]
  $ stop/id=PID

 эти варианты несовместимы. то есть хотите так - ok, хотите
 эдак -- ok, а смешивать низя.. поэтому в vms такое огромное
 количество команд -- для кадого случая своя...

и напоследок цитата отсюда:
http://seqaxp.bio.caltech.edu/www/vms_beginners_faq.html

How do I redirect the input or output of a program?

OpenVMS does not support "pipes" as do some other operating
systems. However, pretty much the same effect can be obtained
by explicitly chaining the output of one program as the input
to the next - so long as what the program produces is text, and
all input/output goes through the standard devices.  In other
words, the equivalent of the Unix command line:

  % prog1 | prog2 | prog3

is:

  $ DEFINE/user sys$output temp1.txt
  $ prog1
  $ DEFINE/user sys$input  temp1.txt
  $ DEFINE/user sys$output temp2.txt
  $ prog2
  $ DEFINE/user sys$input  temp2.txt
  $ prog2

If the intermediate files are not needed afterwards, just delete them.

вот так. это не уних-вэй ;))

>и способ обеспечения их взаимодействия -- шелл

Точнее - потоки(AKA трубы).

>ps -axc | grep process | grep -v grep | cut -f 1 -d ' '

на всякий случай - правильнее так:

kill `ps -o pid=,comm= | grep process | cut -f 1 -d ' '`

первый вариант не находит процессы с именами "*grep*".

Нет, чувак. Когда долгое время работаешь в Linux привыкаешь к KDE-подобным приложениям (Konqueror, Koffice, KDevelop) так что от всего остального просто начинает воротить. Вот это и есть истинный UNIX-way.

> Нет, чувак. Когда долгое время работаешь в Linux привыкаешь к KDE-подобным приложениям (Konqueror, Koffice, KDevelop) так что от всего остального просто начинает воротить. Вот это и есть истинный UNIX-way.

Ты это серьёзно?

kill `ps -o pid=,comm= | grep process | cut -f 1 -d ' '`

можкт так killall process

Unix Way - это "если тебе лень читать что пишет программа, заставь это делать другую программу" (c) не помню.

Это, правда, только одна сторона. Другая сторона - это когда тебе лень что-то писать программе, заставь это делать другую программу :). Это, кстати, не только для CLI. Просто для GUI пока не придумано (или не реализовано? или не получило широкого распространения?) нормального способа такого взаимодействия.

Но даже ненормальными можно иногда пользоваться.

UnixWay(TM) - это такая религия. Догмы следующие:

1) Всё есть файл. Файл - это любая сущность, к которой можно обратиться через read/write/[seek], open/close, ioctl (последнее - в общем-то ересь, и из истинного юнихвэя изгоняется).

2) Нет и не может быть лучшего представления для любых данных, чем текст. Для работы с тектом идеально подходят потоковые фильтры, такие, как sed, awk.

3) Программу любой сложности можно собрать из маленьких и простых кирпичиков, общающихся между собой потоками человекочитабельного текста. Всё вместе склеивается скриптом и потоковыми обработчиками.

Так что, я что-то не догнал, на хера ты сюда C приплёл. Он эквипенисуален.

Как так нереализовано? Как так непридумано? Ты куда последние дцать лет смотрел? Tcl/Tk однако. Оченно легко по пайпикам бегает да awk-ами авкается...

> Tcl/Tk однако.

Ну, всё-таки это не совсем то. Чего-то как-то не хватает :)

А если более конкретно, то можно, скажем, легко получить комбинацию unix-утилит с целью получения какого-то нового поведения (shell-скрипт) и легко потом использовать его наравне с остальными. А вот составные элементы Tk (widgets) более-менее фиксированы. Хотя, в Tix есть всякие там "mega widgets". Правда, я не глядел - насколько там легко создавать свои?

Кроме того, консольным утилитам достаточно перенаправить вводы-выводы для unix-way использования, что не требует никакого изменения и даже знания внутренностей этих утилит. А как перенаправить графический ввод/вывод в Tcl/Tk?

А вот так и перенаправлять. Тулза - wish. По пайпику получает код на Tcl, отдаёт - ну, текст, к примеру, или тоже код.

Это типа следующий метауровень UnixWay - обмениваться не просто текстом, а исполнимым кодом.

Unix Way
Hard to explain. If you're steeped in UNIX, you know the UnixWay. Some facets:

* Everything is scriptable, whether the author intended it to be or not.

* Policy is not decided for you, or reasonable defaults are decided that you can replace with your own.

* Be responsible for what you're doing. You won't be second guessed and prompted. This is the price you
pay for simplicity and an environment that isn't dumbed down.

* Configuration is done via text files that you can edit without complicated tools. Whenever sensible,
data is in text files too. (PowerOfPlainText)

* You can do complicated things by gluing simple things together. (You don't give your editor a word-count
or spell-check feature; you have separate word-counting and spell-checking programs, and teach your editor
to talk to them.)

* Simple and consistent interfaces are good, but they do not generally excuse large and complex
implementations. Complex systems are built on simple cores and not vice versa. (WorseIsBetter)

* Simple and complex systems are better separated from each other, leading to layered rather
than monolithic design. This is synergetic with the point above and is often mistaken for WorseIsBetter.

* write a script first (ie use sh/awk/perl instead of c)

* anything should be possible to be automated.

* You can break any of these rules.

Это довольно громоздко в большинстве случаев. Shell-скрипты ведь не требуют, чтобы на входе-выходе был shell-код, хотя легко позволяют.

Вот если б события Tk ходили через, скажем, 3 и 4 дескрипторы, чтобы можно было вместо "терминала" повесить внешнюю программулину - это было бы уже несколько лучше.

Ведь, что такое, по сути, shell-скрипты? Это что-то вроде макросов (в простейшем случае). Пользователь просто записывает часто повторяющееся действие в файл и имеет возможность параметризовать его. То, что предлагаешь ты (обмен по пайпу кодом на TCL) - слишком громоздко для такого применения. А вот если бы пользователь имел возможность написать "макрос" в виде последовательности нажатия кнопок и ввода значений в поля, или даже "capture" его - было бы очень неплохо. Типа как "Record Macro" в MS Word'е, но там это довольно убого.

Шелл этого не позволяет, по хорошему. У Tcl есть громадное преимущество, что делает подобный финт ушами вовсе не громоздким, и очень даже естественным - у него семантика, основанная на переписывании строки текста. Аналогично и у JavaScript, но он - громоздкий сам по себе, хоть и юзают его таким вот образом довольно таки активно.

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

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

> на всякий случай - правильнее так:
> kill `ps -o pid=,comm= | grep process | cut -f 1 -d ' '`

хуй! ;)

 ~ > ps -o pid=,comm= | grep process | cut -f 1 -d ' '
 ps: comm: illegal keyword specification

про killall:

 ~ > killall
 ksh: killall: not found

правда есть pkill... тогда это аналог ``stop process''.

PS.
~ > uname -a
OpenBSD october.avalon.velcanta.net 3.6 OCTOBER#0 i386

>ps: comm: illegal keyword specification

Ну, это частности. ps у тебя плохой. На hpux-е бородатом, и на OSF-ах всяких и линуксах работает.

> ksh: killall: not found

Бывает сильно хуже:

man killall:

killall - Terminates all processes started by the user, except the calling process

Особенно весело пускать от рута.

> killall - Terminates all processes started by the user, except the
> calling process

это в бородатом хпухе такое живет? :)

я вот кстати поседнее время нетерплю унихи :))
если опен еще как-то так... то уже фря кажется
уродством и полнейшей помойкой... все таки уних
недоделка... а то, что сейчас в нее тащат -- вообще
дерьмо...

пора план9 осваивать...