to post messages and comments.

← All posts tagged unix-way

Когда мы (в том числе и ваш покорный друг) говорим о 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управления. Возможно, что более подробно о них я когда-нибудь напишу

Давно я хочу поговорить о 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, задача выглядит утопично…

Некоторые мои постоянные читатели знают, что я поддерживаю идею использования 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'ий для вывода информации о клавиатуре
и мыши), но суть довольно понятна.

Цитата из 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 пайпы позиционируются как шелл (на сколько я понимаю обыкновенный шелл у них примитивен и не содержит в себе языка программирования)

Решил попробовать использовать 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

UNIX'ач, что ты думаешь о v6 и v7 версиях $subj(1)? С одной стороны v7 обладает такими вещами как lint, yacc, make, tar, uucp, bsh, умеет chroot, с другой именно в ней появляются popen/system и самое главное — костыльный
ioctl.

Буквально на днях Элемир поставил 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, с которым можно было бы запускать шелл
В заключении надо сказать, что я буду рад всякой моральной и физической поддержке моих начинаний