Michae1
unix-way Master-Foo
Однажды к Мастеру Фу явился знаменитый Windows-администратор и спросил его совета:
— Я слышал, ты могущественный волшебник в мире Unix. Не согласишься ли на обмен секретами, от которого мы оба только выиграем?

— Хорошо, что ты ищешь мудрость, — ответил Мастер Фу, — Но в Великом Пути нет секретов.

Администратор выглядел обескураженным:
— Но ведь говорят, что ты — Великий мастер Unix-систем, кто знает глубочайшие их секреты! Как и я в Windows: я сертифицированный инженер Microsoft. У меня имеются и другие знаки отличия, которые в мире встретишь нечасто. Я помню наизусть даже самые мрачные закоулки реестра. Я могу рассказать всё о Windows API, даже те легенды, которые в самом Редмонде уже полузабыты. Что за тайное знание даёт тогда тебе твою силу?

Мастер Фу ответил:
— У меня нет ничего. Ничто не скрыто, нечего и раскрывать.

Возмущённый администратор воскликнул:
— Отлично! Скажи мне тогда, если нет у тебя секретов: что же мне нужно знать, чтобы стать таким же могущественным в Великом Пути как ты?

Мастер Фу промолвил:
— Человек, что принимает секреты за знание, похож на того, кто в поисках света так крепко хватается за свечу, что тушит её пламя и обжигает свою руку.

Услышав это, администратор обрёл просветление.
И другие коаны о Мастере Фу.
Strephil
pacman Arch yaourt unix-way kiss Открыл для себя опцiю pager в yaourt.
Толку от неё немного, потому что всё равно всѣ цвѣта пропадают.
И в самом йогуртѣ это подпилить нельзя — это «фича» package-query.

Забавно. У меня есть pager, который умѣет цвѣта (less -r, напримѣр);
У меня есть программа для работы с базами pacman, которая умеет цвѣтной вывод (package-query).
Написать шелл скрипт, чтобы вывод одного направлял на вход другого? ЭТО НЕВОЗМОЖНО!
KEEP IT SIMPLE, STUPID
Unix way во всѣ поля!

Интересно, есть ли раскраска вывода yaourt для lesspipe? Это же так удобно.
HeX
в голос juick_ppl unix-way macosx-way
<Psihy>
ну у меня вгет по умолчанию стоит же

<HeX>
а у меня макось и я канпиляю

<HeX>
вернее уже сканпилял

<HeX>
и теперь песню качаю

<Psihy>
на маке же покупать все нужно

<Psihy>
а не собирать

<HeX>
юних-вей

<Psihy>
не умеешь ты им пользоваться =\
Rp
работа unix-way тян Работаю в компании с девочкой-линуксоидом. Перечитываю баш, натыкаюсь на bash.im , что и озвучиваю. В итоге решили, что вместо поиска молодого человека следует просто взять коробочку с аминокислотами — и создать идеального прынца. Затеялся спор о том, сколько же аминокислот существует. Найти ответ просто — ищем статью про аминокислоты на википедии, тырим табличку со списком аминокислот, да grep -c "\<tr\>" . Вариант с посчитать, тыкая пальцем в монитор, не рассматривался. о.О
Dimez
unix-way — "Про философию UNIX — херня. Нельзя жить вечно с философией прошлого тысячелетия. Это же IT)"
— "...unix way — продукт мощного инженерного подхода. Как показывает практика, 40 лет он летал, этот unix way и будет летать дальше. Быстро, эффективно и масштабируемо... как по горизонтали, так и в архитектурном плане, вверх"
ППКС
Elemir
unix-way Unix Когда мы (в том числе и ваш покорный друг) говорим о unix way, то чаще всего имеем в виду форму, а не содержание. Консоль, пайпы, всё есть файл, plain text, — именно такие ассоциации у нас вызывает это словосочетание. Но зачастую мы не знаем или не помним ту самую причину, почему UNIX "убил исследования в области системного программирования". Он был лёгким и, что самое главное, он был гибким. Но это для тех задач, которые выполнялись на тех системах. На PDP-11 девайсы либо были поточными, либо их IO проецировался в нереальный диапазон памяти. Что навело на мысль проецировать устройства как файлы (character & block devices). Также он считался офисным и университетским компьютером, так что основные задачи это просмотр/редактирование данных и общение через почту, а работа была в основном интерактивной. Именно поэтому данные выводились в понятном не сверхквалифицированному оператору ПК виде(отсюда plaintext). В конце концов для простоты все файлы представлялись в байтовом виде (в других ОС того времени это было отнюдь не так).
Но мы отвлеклись от темы. Итак UNIX был гибким, если не сказать сверхгибким. Над UNIX v7 с помощью sh+awk+grep можно было сделать всё что душе угодно. Но время шло, задачи менялись, а UNIX (и его форки/клоны) обстрастал слоями легаси. Технологии, которые были когда-то новыми, устаревали, а настраиваемость и целостность системы падали. Именно эти причины в конце 80'ых в недрах Bell Labs зародили идею Plan 9. С одной стороны разработчики plan 9 предугадали бум развития PC, вложили эти идеи в проект системы, усовершенствовали технологии (от которых позже пришлось отказаться, по разным причинам), но с другой он не был таким гибким. Главный идеолог ОС'и, довольно молодой Роб Пайк был приверженцем мыши. В то же время пользователи PC использовали DOS и им в диковинку была система, полностью завязанная на этом устройстве. Другая причина отсутствия гибкости состояла в том, что современник этой операционной системы не обладал даже начальными знаниями основ программирования и сам не мог настраивать систему под себя скриптованием. В результате вышло то, что вышло.
Всё чаще я задумываюсь о том, что мне хочется увидеть этакий современный UNIX. Систему, способную удовлетворить мои потребности по автоматизации произ^wуправления. Возможно, что более подробно о них я когда-нибудь напишу
Elemir
Linux unix-way cli Давно я хочу поговорить о CLI. Что значит это загадочное слово, что таит оно в себе? Если серьёзно, то описать cli не так уж и легко. Банальным способом можно описать cli моделью «комманда → ответ». Она немного наивна, слишком упрощена, но для первого приближения сойдёт.
В общем виде cli утилиты можно разделить на два типа — интерактивные, мнговенные и потоковые. Пример интерактивных утилит — ed или оболочка, примеры мнговенной — ls, cd, pnmtopng, примеры потоковых — sed, cat, awk. Честно говоря, время интерактивных утилит давно прошло, в большинстве своём все интерактивные функции cli-утилит могут быть отданы оболочке, а из утилит этого типа выросли TUI утилиты и модальный интерфейс, как таковой. Да и сам я, признаться, не большой их любитель.
Любите ли вы cli утилиты так, как люблю их я? Ведь их есть за что любить — мало какая технология достигала такого универсализма. Сейчас в толпе пойдёт «фу, ещё один пересаживатель», но нет, никого пересаживать, уговоривать или что-то такое я не собираюсь, но подумайте — можно ли ваши офисы или миранды обернуть в cli? Практически невозможно, а вот сделать обратное не составляет труда (достаточно посмотреть на количество gui и tui фронтэндов к MH) Да, согласен, не все задачи можно решить через CLI, но это явно не мои задачи. Вторая причина, по которой я люблю cli — это то, что он отражает моё мышление. Согласитесь, у многих из нас мышление скорее словесное, чем визуальное. Подумал, написал, получил ответ. Если добавить к этому удобную систему оповещений (такая, например, сделана в некоторых MUD'ах), то использовать его можно для любой необходимой мне задачи, разве кроме вебсерфинга (хотя есть edbrowse…)
Сейчас я перед собой поставил задачу — сделать cli im клиент с возможностью параллелить разные чатики на разные шеллы, скриптовать отсыл/получение сообщений с данного соединения, реализации cli-ростера и прочими вкусностями, вот… Честно говоря, несмотря на полную отрешённость от GUI, задача выглядит утопично…
Elemir
pipeline unix-way Некоторые мои постоянные читатели знают, что я поддерживаю идею использования pipe'ов там, где это возможно. Причины этого довольно понятные — правильно написанные пайпы являются переносимым, нересурсоёмким, легкообратываемым и скриптизуемым IPC.
Но не все до конца понимают сильные и слабые стороны пайпов. Для начала я замечу, что всё написанное далее будет касаться только возможностей систем, работающих с классическими системными вызовами — execve, fork и pipe. Например, BSD'ный rfork или Linux'овый clone справляются с некими проблемами, вставшими тут. Ввиду нестандартности этих решений забудем о них. Нельзя забыть упомянуть Linux'овый системный вызов tee, который также оптимизирует работу с pipe'ами — подробнее о нём можно почитать в GNU-тых man'ах.
Итак — pipe соединяет две программы, какие же условия на них есть? Я утверждаю, что в поставленной задаче существуют только одно существенное условие — «оба процесса моложе чем pipe, либо один процесс старее чем пайп, а второй моложе и является потомком первого». Если понимать принцип работы с pipe'ами, то данное утверждение вполне очевидно (подробно о приципе работы можно разобрать при помощи этого кода cse.lehigh.edu и соответствующих man страниц).
Чем же чревато такое поведение. Тем, что мы можем создавать иерархчически сколь угодно сложные pipe мельницы из новых процессов, но не совсем не можем никак связать два уже существующих процесса. В частности это нас лишает сетевой прозрачности — процессы на разных компьютерах имеют принципиально разных предков.
В то же время не стоит отчаиваться. Пайпы способны порождать очень сложные структуры. Для примера приведу некий абстрактный текстовый редактор. Для этого заведём 2 программы — eed (программа, которая на вход берёт управляющие команды, а на выходе отображение текста) и eterm (на входе — /dev/tty, на выходе — сформированные команды; если хочется vi-style, то оно может работать в модальном режиме, изменяя трансляцию клавиатуры в команды в зависимости от своего внутреннего режима ). Сам редактор (emanager) запустит одну копию eterm'а, одну копию eed и будет транслировать команды eterm в команды eed. Если eed пришлёт команду new-window, то он создаст новую копию eed и так далее. На практике всё может осложнятся работой с большим кол-вом файловых дескрипторов и пайпов (например вывод eed можно перехватывать и отдавать программе edm, которая занимается вводом/выводом на экран и кроме 1'ого дескриптора, который выводится на дисплей, у него есть 2'ой и 3'ий для вывода информации о клавиатуре
и мыши), но суть довольно понятна.
Elemir
pipeline mpg123 unix-way Цитата из man page'а mpg123 «--fifo path Create a fifo / named pipe on the given path and use that for reading commands instead of standard input.» Вот что приходится делать из-за отсутствия двух стандартных вводо-выводов, как у Хартманна. Основная идея Хартманновских пайпов — наличие у любой программы, кроме привычной пары std{in,out} ещё и secondary пару. Обыкновенная unix-like мельница pipe'ов (p1 | p2 | ... | pn) соединяет только primary ввод-вывод. Для работы с secondary есть так называемые метки. Они имеют вид foo: и могут стоять в мельнице как перед программой (p1 | l1: p2 | p3), в таком случае оно соединяется с secondary вводом-выводом программы (не у всех программ таковой имеется — на то он и вторичный), так на месте программы (l1 | p4). Такая гибкая система позволяет строить сколь угодно сложные графы передачи информации между программами, а при правильном наборе программ ещё и становится тьюринг-полной. В виду последнего свойства в CMS/TSO пайпы позиционируются как шелл (на сколько я понимаю обыкновенный шелл у них примитивен и не содержит в себе языка программирования)
Elemir
Linux FB unix-way Решил попробовать использовать fifo для мультиплексинга virtual framebuffer. В этом сражении Linux меня выиграл
elemir@desktop:~$ mkfifo test && FRAMEBUFFER=./test fbi -f terminus a_7a1349b8.jpg
using "Terminus-12", pixelsize=12.00 file=/usr/share/fonts/X11/misc/ter-u12n_iso-8859-1.pcf.gz
ioctl FBIOGET_VSCREENINFO: Invalid argument
Kim
unix-way Путь юникс, то есть рекомендации по проектированию систем от Кернигана и Пайка, а не Великое Учение По Постороению Безупречных Систем, имеет ряд общеизвестных проблем. Самая банальная из них заключается в том, что UNIX-way не признает существования сложных задач. Согласно советам по дизайну программ [ werc.homelinux.net ] каждую сложную задачу можно разделить на несколько простых и решать их по отдельности. К сожалению это не так. Простые задачи покрывают сложную не полностью, и всё равно требуются тысячи строк кода при отходе от стандартного шаблона использования. В качестве иллюстрации напишу про ситуацию с текстовыми потоками:

Если мы хотим соединить две программы в одну, то всё здорово:
$ cat a b c | gzip -c >data.gz
Если мы хотим при этом параллельно делать ещё какую-то вещь с выводом первой команды, то мы можем написать
$ cat a b c | tee >(gzip -c >data.gz) | grep WARNING
либо
$ cat a b c >/tmp/temp.data ; gzip -c /tmp/temp.data >data.gz & grep WARNING /tmp/temp.data ; wait $! ; rm /tmp/temp.data
несмотря на то что задача фактически не изменилась нам потребовалось, в первом варианте, переписать шелл добавив в него конструкцию >(shell command), кроме того потребовалась реализация программы tee, которая имеет один вход и много выходов. Второй вариант ещё более ужасен: потребовалось создание временного файла который занимает место на диске, потребовалась реализация асинхронного вызова и примитива wait, потребовался код для удаления временного файла. Скажу сразу: первый вариант больше соответствует идеям указанной выше статьи по дизайну програм. Казалось бы это уже конец. Но нам может захотеться вставить разную обработку перед вводом. Тогда придётся писать:
$ cat a <(grep USEFULL b) c | gzip -c >data.gz
либо
$ mkfifo /tmp/b.fifo ; grep USEFULL b >/tmp/b.fifo & cat a /tmp/b.fifo c | gzip -c >data.gz ; rm /tmp/b.fifo
что снова требует добавления ряда конструкций.

В bash указанные задачи решены добавлением тех самых >(...) и <(...), но легко придумать задачи где этих методов соединения текстовых потоков недостаточно и придётся создавать всё более страшные конструкции (скорее всего похожие на вторые варианты решений указанные выше) до тех пор, пока вся система не рухнет под своим весом. С другой стороны если сразу решать задачу как сложную и реализовать систему для произвольного соединения текстовых потоков, то в сумме решение получится проще, компактнее и полнее чем объединение "маленьких утилит решающих свои задачи".
Elemir
древность unix-way Unix UNIX'ач, что ты думаешь о v6 и v7 версиях $subj(1)? С одной стороны v7 обладает такими вещами как lint, yacc, make, tar, uucp, bsh, умеет chroot, с другой именно в ней появляются popen/system и самое главное — костыльный
ioctl.
partizan
unix-way теперь я делаю вместо "открыть mc распаковать архив запустить скрипт" вот так: unxz -c dump.sql.xz | convert-to-sqlite.py > dump.sql
следующий уровень: вместо > dump.sql писать сразу | sqlite3 file.db
Elemir
Plan9 unix-way критика Буквально на днях Элемир поставил plan 9 на нетбук bare metal. Общее впечатление хорошее, система устроена довольно чётко и красиво. На данном этапе возникает ощущение, что превратить его в систему, на которую можно поставить наклейку "Elemir thinks it's usable". До этого я себя так чувствовал только в FreeBsd (почему не в {Open,Net}BSD отдельный разговор) и то оно было намного менее яркое. Понятное дело, что в бочонке меда есть своя ложка дегтя. Демонстрировать я её буду придераясь к конкретным частям системы.
* acme — самый популярный редактор для plan 9. По сути своей тот же emacs только с 9p и без лиспцов. Никаком боком не вписывается в общую философию нового UNIX, что он тут делает — непонятно. Решение — выпилить из стандартной поставки
* sam — другой известный редактор для нашей няшечки. Тут всё намного сложнее. С одной стороны редактор имеет неплохое устройство, но с другой стороны — многое было сделано не адекватно. Сам редактор можно было сделать консольным, output которого бы распределялся между samterm'ами
* rio — оконный менеджер plan 9, одна из самых сложных программ этой системы. Как водится в его проектировании был допущен ряд недочётов. С эдной стороны OS позиционирует себя как наследника UNIX, с другой в rio нельзя прикрутить управление в клавиатуры без правки исходников. Моей целью в этом направлении является включение возможности управлять shortcut'ами, задавать функции rc, выполняемые при разных событиях и на основе этого создать тайлинг-скрипт
* rc — тут всё сделано хорошо и без излишеств. Простой скриптовый язык. Надо только заметить, что системе сильно не хватает чего-то в духе rlwrap, с которым можно было бы запускать шелл
В заключении надо сказать, что я буду рад всякой моральной и физической поддержке моих начинаний
Michae1
HowTo Linux unix-way Вчера возникла необходимость рекурсивно пройтись по самбовой шаре и скопировать из всех вложенных папок файлы в одну локальную кучу. Мы выбираем unix-way :)
Сначала наткнулся на smbclient. Узнал про него много нового и интересного, и даже научился рекурсивно копировать файлы, но делу это не помогло — структура каталогов упорно сохранялась.
В это время мой unix-сенсей @adept- посоветовал смонтировать всё через smbmount. Ok. Монтируем, но русские символы закрыты вопросиками. Гуглим... Ага, вот так надо: sudo smbmount //192.168.1.4/maxtor-downloads /media/smb -o iocharset=utf8, codepage=cp1251.
Хорошо, гуглим дальше, и находим вот это: find /media/smb/Майкл\ Джексон\ \(Michael\ Jackson\)\ дискография/ -name '*.mp3' -exec cp {} /media/KATYA/Michael_Jackson/ \;. Всё прекрасно, всё отлично... только медленно. 2 гига по вай-фаю... этого следовало ожидать.
Супруга предлагает дойти с флешкой до сервера в соседнюю комнату. Что ж, на это мы благоразумно соглашаемся. Теперь нужно просто зайти через ssh на сервер и проделать процедуру локально. Ищем воткнутую флешку: fdisk -l /dev/sdb. Так, это винт fdisk -l /dev/sdc — ага, то, что нужно. Монтируем: mkdir /media/katya; sudo mount /dev/sdc1 /media/katya/, запускаем find — процесс пошел...
Быстрее-то оно, конечно, быстрее, но тем не менее, уже хочется спать, а не смотреть, как всё это копируется. А выключать комп, разрывая ssh-сессию нельзя. И тут мы узнаем про такое чудо, как screen, позволяющее отвязывать долгоиграющие процессы от запустившей их сессии. Но в данной конкретной ситуации юзать его было уже поздно, так что пришлось дождаться окончания копирования, вырубать технику и отправляться спать.
Мораль: казалось бы, тривиальная задача скинуть файлы из разных папочек в одну вылилась в увлекательное и познавательное времяпрепровождение, общение с друзьями и чувство восторга, когда всё заработало. Вот за это и люблю Linux :)