Компьютерра, 2006 № 05 (625) - [29]
Собственно, сам 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, получая в распоряжение всю мощь платформы.
