Боб Уэллс Консультант по программному обеспечению; специализируется на вопросах проектирования и реализации инфрастуктуры информационных систем, основанных на NT. Имеет сертификаты MCSE и MCT. С ним можно связаться по адресу bobwells@winntmag.com.

Вэтой статье я расскажу о задачах, решение которых можно автоматизировать при помощи Windows Scripting Host (WSH) 1.0. До сих пор я почти не уделял внимания фундаментальным основам WSH. Поскольку я получаю по электронной почте многочисленные вопросы о WSH и Visual Basic Scripting Edition (VBScript), многим системным администраторам, думаю, будет полезной базовая информация о сценариях.

В нескольких последующих статьях я сделаю шаг назад, чтобы обсудить некоторые основы WSH-сценариев. Чтобы заинтересовать и опытных пользователей, я дам ряд полезных советов, а также напишу о WSH 2.0.

WSH может казаться трудным в изучении по ряду причин. Большинство трудностей, на мой взгляд, связано с нехваткой качественных источников информации. WSH пока является новой технологией, и по мере ее совершенствования, я надеюсь, будут появляться хорошие документы. Ну а пока за сведениями о WSH обращайтесь к публикациям и Web-узлам, перечисленным во врезке «Источники информации о Win32-сценариях».

Еще один фактор, затрудняющий изучение WSH — большое количество на первый взгляд несвязанных технологий, которые необходимо освоить, чтобы заставить WSH-сценарии выполнять различные функции. Например, чтобы написать сценарий, определяющий название группы, к которой принадлежит пользователь, необходимо знать что-то о WSH, VBScript или JScript, а также о Active Directory Service Interfaces (ADSI). Гораздо меньше знаний понадобится, чтобы выполнить ту же самую задачу с помощью специализированного языка сценариев под названием KiXtart, языка пакетных файлов или утилиты вроде Ifmember из NT Server 4.0 Resource Kit.

Сложность не только в том, что WSH нередко требует знания нескольких скриптовых технологий; поскольку они частично перекрывают друг друга, приходится выбирать, которую же использовать для выполнения того или иного задания. Например, и ADSI, и Windows Management Instrumentation (WMI) — реализация Web-Based Enterprise Management (WBEM), предложенная Microsoft, — обеспечивают доступ к службам NT через интерфейсы автоматизации. Если вы хотите запускать и останавливать сервисы на NT-сервере при помощи WSH, вам необходимо решить, чем пользоваться — WMI или ADSI.

Учитывая нехватку документации по WSH и разнообразие технологий, которые в WSH-сценариях могут быть задействованы, новая модель Windows-сценариев Microsoft действительно может показаться сложноватой. Однако приложив некоторые усилия к изучению WSH, с его помощью вы сможете достигнуть гораздо большего, чем за счет любой другой технологии. Поверьте — знания, которые вы приобретете, будут стоить затраченных усилий.

В серии статей об основах WSH я намерен рассказывать о сценариях VBScript. WSH-сценарии становятся все распространеннее в Internet, и большинство из них написаны на VBScript. Кроме того, примеры WSH-сценариев, сопровождающие некоторые продукты и технологии Microsoft (в частности, комплект средств разработки ПО для ADSI, Internet Information Server , Site Server, комплект средств разработки для WBEM), написаны на VBScript. VBScript 5.0 можно загрузить с Web-узла Microsoft по адресу http://msdn.microsoft.com/scripting/vbscript/default.htm). В первой статье серии «Основы WSH» я расскажу, как писать сценарии на VBScript, как заставить несколько скриптов выполнять общую задачу и как структурировать сценарии VBScript.

WSH-сценарии на VBScript — это обычные текстовые файлы ASCII с расширением .vbs. Создавать файлы на VBScript можно в любом текстовом редакторе, способном сохранять документы в формате «только текст» (например, в Visual Notepad, Visual InterDev). Конечно, содержимое такого файла должно представлять собой корректный код на VBScript. По размеру сценарии могут разниться от одной до тысяч строк. Единственное ограничение на размер сценариев — лимит, налагаемый операционной системой. На системах с NT максимальный размер сценариев на VBScript ограничивается предельным размером файла. (Чтобы убедиться в том, что WSH способен выполнять большие сценарии, я создал сценарий длиной более чем в 25 тыс. строк; он работал безупречно.)

Хотя WSH не налагает ограничений на размер файла, WSH-сценарии в текущей версии не могут располагаться более чем в одном файле. WSH 1.0 не поддерживает включаемые файлы — файлы, содержащие процедуры, которые могут быть запущены на выполнение из основного сценария. Это ограничение можно обойти несколькими путями. Можно использовать метод Run объекта WSH Shell для запуска внешних сценариев (как и любых других внешних команд). Но проблема в том, что два сценария не могут использовать одно и то же именное пространство, то есть не имеют взаимного доступа к переменным и процедурам друг друга.

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

В листинге 1 приведен сценарий include.vbs, в листинге 2 — main.vbs. Include.vbs содержит подпрограмму под названием Usage с одним аргументом строчного типа. Содержимое этой строки подпрограмма выводит на экран при помощи метода Wscript.Echo.

Main.vbs считывает в переменную strCode содержимое подпрограммы Usage из файла include.vbs, а затем вызывает ее. Для создания ссылки на объект TextStream, являющийся указателем на файл include.vbs, используется метод OpenTextFile объекта VBScript FileSystemObject. Затем с помощью метода TextStream.ReadAll содержимое файла include.vbs помещается в переменную strCode.

После этого main.vbs передает переменную strCode в качестве аргумента команде Execute, которая таким образом делает подпрограмму Usage частью сценария main.vbs. В последней строке сценария вызывается подпрограмма Usage, которой в качестве аргумента передается строка для вывода на экран. На экране 1 показан результат запуска main.vbs.

Хотя вызов Usage, на первый взгляд, обращается к подпрограмме, находящейся в другом файле, на самом деле это не так. Подпрограмма Usage становится частью именного пространства main.vbs, как только этот сценарий передает строку с ее кодом команде Execute. Поэтому не забывайте, что подпрограмму с названием, соответствующим имени одной из процедур, уже использующихся в сценарии, «затаскивать» в него из другого файла нельзя (если, конечно, вы не хотите динамически модифицировать код процедуры).

В WSH 2.0 появится поддержка включаемых файлов и возможность создания библиотек часто используемых функций и подпрограмм, к которым можно осуществлять доступ из других сценариев независимо от языка, на котором они написаны. WSH 2.0 позволит также вызывать функции JSсript из программ на VBScript и наоборот.

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

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

Я делю мои WSH-сценарии на три секции: секция декларации и инициализации, тело сценария, секция задания функций и процедур. В первую секцию я помещаю директивы интерпретатора, декларации переменных, а также код инициализации констант и переменных. Команды сценария и код, управляющий его поведением, я располагаю во второй секции. В теле сценария я помещаю в память и использую объекты, вызываю методы, устанавливаю свойства, обращаюсь к процедурам и функциям. Наконец, секция функций и процедур в конце сценария у меня предназначена для разделения кода на блоки. Здесь помещаются части кода, которые используются внутри сценария по нескольку раз.

Из трех введенных мною секций сценария обязательно лишь тело. Чтобы сценарий действительно был сценарием, он должен содержать по меньшей мере одну корректную команду. Однако VBScript не требует обязательного определения и инициализации переменных перед использованием; не требуется также и обязательное разделение кода на процедуры и функции. Способ структурирования сценариев вы выбираете самостоятельно. Я помещаю определения и инициализации в начале сценария, чтобы было проще читать и исправлять код; но кроме такого подхода существуют и другие. Некоторые разработчики, например, задают все процедуры и функции в начале сценария. Другие задают каждую процедуру непосредственно перед первым ее вызовом. (В нескольких примерах сценариев, сопровождающих WSH 1.0, используется именно такая структура.)

В следующей статье серии я каждую из трех своих секций опишу в подробностях. А пока вы можете обратиться ко врезке «Источники информации о Win32-сценариях». Велика вероятность, что вы узнаете что-то новое.