Журнал «Компьютерра» № 5 за 7 февраля 2006 года

Софтерра: Современная монадология

Автор: Сергей Поляков alexei@samara.net

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

Опытный администратор Unix может выполнять многие действия в командной строке быстрее, чем с использованием самого удобного графического интерфейса. Дело в том, что в этой нелегкой работе ему помогает множество инструментов:

Собственно, сам shell. В простейшем случае оболочка, приняв строку от пользователя, находит в системе соответствующую программу, выполняет ее и выводит результат в виде обычного текста. Примерами для Unix являются bash, csh, tcsh, zsh, psh и т. д. Продвинутые оболочки облегчают ввод данных, предлагая выбор из ограниченного количества вариантов команд и их параметров.

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

Композиционная модель системы: большое количество слабо связанных друг с другом простых программ-утилит (awk, sed, grep, sort, …). Объединяя команды в цепочку (pipeline), можно реализовать весьма сложные процессы обработки данных и управления системой.

Клавиатура, с которой он давно сросся.

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

До недавнего времени все это относилось в основном к Unix-системам. Ни для кого не секрет, что, несмотря на наличие некоторой командной строки в Windows, управлять продуктами Microsoft с ее помощью не слишком удобно. Графический интерфейс де-факто является стандартным средством управления в операционных системах Windows, и зачастую функции GUI не имеют аналогов командной строки, даже для серверных продуктов. И наоборот, функционал текстовых утилит не всегда реализован в GUI. Так было до появления проекта под кодовым названием Monad. О нем и пойдет речь в этой статье.

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

C:\ > echo «Mother washes winsodsdsd» > text.txt

C:\ > $wordApp = new-object —com Word.Application

C:\ > get-content (dir *.txt) | foreach { $_.Split(‘ ‘) } | where { !$wordApp.CheckSpelling($_) } | sort -Unique

winsodsdsd

C:\ >

Более подробный код находится на сайте разработчиков Monad. Существует бесконечное множество способов использовать функции продуктов Office в своих программах и тем более скриптах.

Нельзя сказать, что невеселое положение дел на «командном» фронте устраивало Microsoft — на всем протяжении развития Windows предпринимались попытки улучшить ситуацию в этой области (см. табл. 1). Однако имеющиеся недостатки не позволяли командной строке стать полноценным инструментом.

В command.com и его потомке cmd.exe команды не являлись отдельными программами, как в Unix, а были реализованы непосредственно в самой оболочке. Эта особенность, по-видимому, препятствовала расширению функциональности системы. Команды command.com и cmd.exe оставались плохо документированными и бедными по возможностям, тогда как программы-утилиты Unix-систем активно развивались сообществом пользователей. Кроме всего прочего, обе оболочки не соответствовали стандарту POSIX, разработанному для Unix-оболочек. Следовательно, сценарии, написанные для POSIX-оболочек, не могли быть адаптированы под cmd.exe — равно как и опыт администраторов.

Services For Unix (SFU), разработанные еще для Windows NT, предназначались для упрощения задач по интеграции Windows— и Unix-систем. По сути, SFU — это Unix-система, которая запускается под управлением Windows. В ее состав входят ключевые Unix-сервисы, POSIX-совместимые программные оболочки и более трехсот утилит.

Поначалу продукт не был включен в состав операционной системы — его нужно было приобретать отдельно. И хотя сейчас SFU свободно распространяется и даже входит в Windows Server 2003 R2, коммерческое распространение не способствовало ее популярности. Кроме того, чуждая для Windows модель POSIX оказалась плохо совместимой с большинством продуктов, изначально делавшихся для Windows.

Windows Scripting Host (WSH), разработанный для всех версий Windows, предоставляет доступ к управлению системой с использованием сценариев, написанных на Jscript или VBscript. Однако он не был интегрирован с командной строкой. Непрозрачная документация, сложность в изучении и большое количество вирусов, использующих WSH, не позволили технологии получить широкое распространение.

Несмотря на то что в Windows явно ощущается дефицит полнофункционального консольного интерфейса, программный интерфейс управления системой существует давно: это Windows Management Instrumentation (WMI). История Monad начинается в 2000 году, когда Джеффри Сновер (Jeffrey Snover), архитектор продукта, приступил к созданию пользовательского интерфейса командной строки для WMI, названного WMIC. Пользователи Windows XP и Windows Server 2003 могут ознакомиться с ним, набрав в стандартной командной строке «wmic.exe», и получить справку о командах с помощью команды «/?». Интерфейс получился недостаточно стройным, ориентированным прежде всего на функциональные особенности WMI, а не на пользователя. Этот факт еще мог устроить корпорацию Microsoft, чьи продукты поддерживали WMI, но вряд ли обрадовал разработчиков сторонних компаний, не использующих этот интерфейс. Функциональность WMIC расширялась плохо, поскольку реализована была точно так же, как и в cmd.exe. В то же время инструменты управления продуктами Microsoft подвергались критике Главного Архитектора (Билл Гейтс) из-за слабого использования .NET-языков. Было решено переписать WMIC на C#. В определенный момент Сновер понял, что не обязан ограничиваться классами WMI и может использовать в своем продукте любые классы .NET, получая в распоряжение всю мощь платформы.

Был создан прототип интерфейса, а затем сформирована команда проекта Monad.Знакомство

Итак, Monad (она же Microsoft Shell, или MSH) — это будущая платформа для администрирования операционной системы и программных продуктов Microsoft. Cамая важная идея, заложенная в MSH, состоит в том, что в знакомой нам командной строке вывод результатов команды представляет собой не текст (в смысле последовательности байтов), а объект (данные вместе со свойственными им методами). Все! Остальное так или иначе вытекает из этой идеи.

Вот главные цели, преследуемые разработчиками Monad:

командная строка как основной интерфейс администрирования;

реализация ObjectFlow (элементом обмена информации является объект);

переработка существующих команд, утилит и оболочки;

интеграция командной строки, COM— и .NET-объектов;

работа с произвольными источниками данных в командной строке по принципу файловой системы.

По словам разработчиков, сильное влияние на Monad оказали следующие продукты:

BASH, KSH — композиционность;

AS400/VMS — стандарт синтаксиса именования команд, облегчающий изучение;

TCL/WSH — поддержка встраиваемости и нескольких языков;

PERL, PYTHON — выразительность и стиль.

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

В качестве примера я написал плагин, который позволяет управлять воспроизведением музыки в Monad (полный код можно найти в [4]). Ниже приведена реализация команды play-nextsong на языке C#, которая переключает воспроизведение на следующую композицию:

[Cmdlet(«play», «nextsong»)]

public class PlayNextSongCommand : Cmdlet

protected override void EndProcessing()

Media.Player.controls.next();

Этого достаточно чтобы пользователь смог найти команду и узнать, как с ней работать:

Media:\Slayer\Reign In Blood> get-command play*

Command Type Name Definition

— — —

Cmdlet play-nextsong play-nextsong [-Verbose…

Cmdlet play-previoussong play-previoussong [-Ver…

Cmdlet play-song play-song [[-MshPath] S…

Можно усложнить команду, добавив к ней несколько параметров. Даже если разработчик не позаботился о документации, пользователь сможет получить автоматически генерируемую справку о формате ее вызова и типах параметров:

Media:\Slayer\Reign In Blood> get-command play-nextsong —Synopsis

play-nextsong [[-SkipSongCount] Int32] [-Verbose] [-Debug] [-ErrorAction ActionPreference] [-ErrorVariable String] [-OutVariable String] [-OutBuffer Int32]

А вот так выглядит листинг содержимого текущей директории. Директория не обязательно файловая, это может быть контейнер любых объектов, в нашем случае это альбом, а содержимое — композиции:

Media:\Slayer\Reign In Blood> ls

Number Name AlbumName ArtistName Year

— — — —

1 Angel of Death Reign In Blood Slayer 1986

2 Piece By Piece Reign In Blood Slayer 1986

3 Necrophobic Reign In Blood Slayer 1986

Что же дает Monad различным категориям пользователей? Программисты, например, смогут ускорить реализацию интерфейсов управления к разрабатываемым системам. Для того чтобы создать новую команду, достаточно унаследовать свой класс от класса Cmdlet и вызвать из него специфичную функцию системы (см. врезку). Отметим, что, реализовав интерфейс управления к своей программе таким образом, разработчик не ограничивается только командной строкой. Стандартная графическая консоль управления Microsoft Management Console (MMC), используемая в Windows XP и Vista, будет понимать модули, написанные для Monad.

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

Администраторы смогут скомпоновать из разных блоков командную оболочку для определенных типов задач. Ее можно указать в качестве сценария запуска (login shell) при входе определенной группы пользователей в систему — локально или удаленно. Тем самым можно ограничивать функции, доступные пользователям, а требования к пропускной способности канала в случае распределенной системы будут минимальными, достаточными для протокола telnet.

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

Не могу удержаться от соблазна сразу же привести пример. Людям, знающим предметную область, он многое объяснит.

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

Я попросил специалиста Unix shell быстро, не зарываясь в man, написать такой скрипт.

Решение SH:

%>ps -A -sort ‘%cpu’ -format ‘%cpu,pid’ | egrep -v ‘^ (0|1|2).’ | grep -v ‘%CPU’ | tail —n3 | gawk ‘{print $2;}’ | xargs -r kill

Скрипт написан за семь минут, работает, и я его привожу как есть — без исправлений. Не буду объяснять, как он работает, отмечу лишь, что главной проблемой является необходимость выделения из набора строк, возвращаемых командой ps, нужные нам параметры процессов (в данном случае — процессоное время).

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

Решение Monad:

C:\> get-process | where-object { $_.cpu -gt 3 } | sort-object -property cpu | select-object -Last 3 | foreach-object { $_.Kill() }

get-process — функция, возвращающая массив объектов типа System.Diagnostics.Process;

where-object — функция условия, которая сравнивает значение свойства с тройкой;

$_ — переменная, содержащая элемент массива — объект класса Process;

sort-object, select-object — сортировка и фильтрация массивов;

foreach-object — выполнить код для каждого элемента, в нашем случае — вызвать метод объекта — Kill()

Эту же строку можно написать с использованием алиасов:

C:\> ps | where { $_.cpu -gt 3 } | sort cpu | select -Last 3 | foreach { $_.Kill() }

Читаемость варианта Monad даже не имеет смысл сравнивать с SH-скриптом. Написано за минуту.

Не будет преувеличением сказать, что Monad — это качественный скачок, переосмысление накопленного опыта в области управления операционных систем. В заключение несколько слов о том, когда же наступит светлое будущее.

Релиз Monad должен появиться в составе Microsoft Exchange Server 12. Он работает на системах Windows XP, Windows Server 2003 или других системах, поддерживающих .NET Framework 2.0. Beta 3 находится в свободном доступе (download.microsoft.com).

Ссылки

[1]blogs.msdn.com/monad/de-fault.aspx (сайт разработчиков Monad).

[2]www.microsoft.com/tech-net/scriptcenter/hubs/msh.mspx

[3]www.reskit.net/monad.

[4]blogs.gotdotnet.ru/perso-nal/beerbong (блог автора статьи).

[5] Издательство O’Reilly в декабре 2005 года выпустило книгу «Monad» (ISBN: 0-596-10009-4), написанную одним из авторов платформы Энди Оукли (Andy Oakley). Это, пожалуй, самый лучший способ познакомиться с продуктом.

Автор благодарит Константина Беляева за доклады на GotDotNet User Group.