Журнал «Компьютерра» № 5 за 7 февраля 2006 года
Шрифт:
Вовсе не обязательно каждый раз открывать текст в редакторе 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:\ >
Более подробный код
Нельзя сказать, что невеселое положение дел на «командном» фронте устраивало 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]
А вот так выглядит листинг содержимого текущей директории. Директория не обязательно файловая, это может быть контейнер любых объектов, в нашем случае это альбом, а содержимое – композиции: