Автоматическая проверка аргументов

. Одно из них - объект WshArguments, предоставляющий разработчикам простой механизм считывания имеющихся в командной строке аргументов, их типов и значений. Второй инструмент, используемый в файлах .wsf (Windows Script File) - это элемент XML , позволяющий автоматизировать генерацию файла подсказки «Справка». В файлах .wsf в целях упрощения идентификации при добавлении в сценарий элементов справки используется разметка, принятая в документах формата XML. Для ссылки на эти элементы используются имена их тегов (tag names), представляющие собой собственно имена элементов, заключенные в угловые скобки "<>", которые используются для выделения тегов. В характеристиках этих средств достаточно просто запутаться. Разработчики сценариев часто считают, что элементы и элемента выполняют проверку введенных пользователем аргументов, хотя в действительности эти элементы просто формируют хорошо отформатированный текст «Справки». Как отмечал ранее Боб Уэллс, данные элементы не занимаются проверкой вводимых пользователем аргументов. Другими словами, даже если в элементах и сценария .wsf детально описывается использование аргумента (т.е. какие параметры являются обязательными, какие дополнительными, какие типы значений могут принимать аргументы, сколько должно быть аргументов), тем не менее, для проверки этих аргументов необходимо разрабатывать некоторые дополнительные программные процедуры.

Хотя WSH и упрощает процедуру проверки, у разработчика все равно остается достаточно пространства как для ошибок, так и для дополнительной работы. Например, можно изменить используемые в сценарии аргументы, забыв при этом отразить внесенные значимые изменения в справочной информации. Вполне возможно, что процедуры проверки аргументов в разных сценариях могут слегка отличаться, поэтому вы будете вынуждены потратить лишнее время, переписывая похожие фрагменты кода по нескольку раз. К счастью, обработку содержимого тега достаточно просто организовать, используя компоненты Microsoft XML, поэтому можно написать такую программную процедуру, которая бы автоматически проверяла введенные пользователем аргументы на соответствие спецификации runtime.

В данной статье мы рассмотрим некоторые нюансы использования элемента в сценариях .wsf, а также коллекции WshArguments. Кроме того, я наглядно продемонстрирую (с помощью кода, показанного в Листинге 1) тот факт, что WSH не проверяет пользовательские аргументы на соответствие элементам и . Далее мы познакомимся с компонентом .wsc (Windows Script Components), который был разработан мною для автоматизации проверки аргументов сценариев .wsf. Чтобы показать, как работает этот компонент, я использую сценарий WSH с именем tee.wsf, который считывает символы из стандартного входного потока командной консоли и записывает их в стандартный выходной поток, а также в один или более файлов. Далее будет показано, как с помощью созданного мною компонента можно автоматизировать процедуру проверки аргументов, добавив в сценарий всего лишь четыре строки кода. Теперь и в вашем распоряжении будет удобный инструмент, который вы в дальнейшем сможете использовать в других сценариях.

Элемент и коллекция WshArguments

Как упоминалось выше, в сценарии .wsf в разделе можно документировать используемые аргументы. Более подробно элемент описан в документации Microsoft, адрес: http://msdn.microsoft.com/library/en-us/script56/html/wslrfruntimeelement.asp. Для того чтобы ознакомиться со справочной информацией по использованию аргументов командной строки сценария, пользователь должен запустить сценарий с ключом "/?". Другой подход предполагает вызов сценарием метода WScript.Arguments.ShowUsage. Я предпочитаю ссылаться на раздел в качестве спецификации аргументов (arguments specification), поскольку эта конструкция позволяет непосредственно указать пользователю, какие требования предъявляются к аргументам командной строки для корректного запуска сценария.

В отличие от только что описанного варианта, коллекция WshArguments позволяет получить данные о реальных аргументах, введенных пользователем, внутри сценария. Чтобы получить более полную информацию о коллекции WshArguments, обратитесь к документации Microsoft по адресу: http://msdn.microsoft.com/library/en-us/script56/html/wsobjwsharguments.asp.

Проблема: отсутствие проверки аргументов

Для того чтобы понять суть проблем, обусловленных непроверенными аргументами в сценариях WSH, взгляните на некорректно написанный сценарий, показанный в Листинге 1. Если сохранить его с расширением .wsf, а затем запустить в командной строке с ключом "/?", в результате на экране отобразится следующая справочная информация:

listing1.wsf /O[+|-]
  /C:value file1 [file2...]

Для тех, кто не знаком с синтаксисом аргументов командной строки, поясню, что квадратные скобки ( [] ) обычно используются для обозначения необязательных параметров. Единственным исключением является случай, когда значения в квадратных скобках разделены символом вертикальной черты ( | ); это означает, что пользователь должен выбрать одно из указанных значений. Применительно к показанной выше команде это означает, что пользователь должен использовать параметр /O+ или /O-, но не может использовать просто /O. Все параметры, не заключенные в квадратные скобки, являются обязательными. Иначе говоря, в соответствии с данными справки, для этого сценария являются допустимыми две простейшие командных строки:

listing1.wsf /O+ /C:value file1

и

listing1.wsf /O- /C:value file1

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

Решение: компонент для проверки

Простейший способ обеспечения соответствия между текстом справки и процессом проверки аргументов состоит в разработке процедуры, которая анализирует элементы XML в разделе , а затем проверяет введенные пользователем аргументы на соответствие описанию XML. Для этих целей мною был создан компонент wshargex.wsc, который показан в Листинге 3. Для автоматизации процесса проверки нужно установить компонент wshargex.wsc, проверить, являются ли ваши сценарии XML-совместимыми файлами с расширением .wsf, а затем просто вызывать из сценариев данный компонент для выполнения проверки.

1. Установка wshargex.wsc. Убедитесь, что на компьютере установлен WSH версии не ниже 5.6 – это необходимо для того, чтобы можно было работать в сценарии с аргументами Named и UnNamed как с отдельными коллекциями. Запустите Проводник Windows, щелкните правой кнопкой на компоненте .wsc и выберите пункт Register. Если регистрация .wsc компонента прошла успешно, вы увидите сообщение, похожее на DllRegisterServer and DllInstall in C:WindowsSystem32scrobj.dll succeeded. Если вы хотите зарегистрировать компонент wshargex.wsc из командной строки, используйте следующую команду:

regsvr32 /s /i:"full-wsc-path"
  %systemroot%system32 scrobj.dll

где full-wsc-path – описание пути к wshargex.wsc на вашем компьютере.

Ключ "/s" отключает вывод диалогового окна regsvr32 (тем не менее, в командной строке при неудачной регистрации regsvr32 будет выдавать ошибку). Удостоверьтесь, что вы зарегистрировали локальную копию компонента, так как процедура регистрации указывает системе Windows путь для его поиска, поэтому если вы регистрируете компонент, размещенный в сети, в дальнейшем он может быть недоступен.

2. Создавайте свои .wsf-сценарии в соответствии с форматом XML. В документации по WSH подробно описывается, как создавать сценарии XML (для получения более подробной информации обратитесь к статье "Script Component Files and XML Conformance" по адресу http://msdn.microsoft.com/library/en-us/script56/html/letxml.asp.)  Все изложенное ниже относится как к файлам .wsf, так и к компонентам .wsc.

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

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

encoding="ISO-8859-1"?>

Далее, для того чтобы "скрыть" элементы вашего сценария, необходимо применить теги CDATA, как показано в прилагаемых листингах и приведенном ниже примере:

Инструкция "" как буквенные символы. Если не использовать тег CDATA, то при анализе кода XML служебные символы, такие как угловые скобки или знак амперсанда (&) будут обрабатываться, а не рассматриваться как обычные элементы текста сценария. Тег CDATA может использоваться для отключения обработки специальных символов XML внутри любого элемента, такого как , , ,

Листинг 2. tee.wsf

Name: tee.wsf

 

Description:

Reads data from a console standard input stream and writes it

  both to the named file(s) and to console standard output.

MUST explicitly use cscript.exe on the command line.

]]>


To run netstat and echo output to the file C:
etstat.txt as well as

  console output, use the following command line:

    netstat | cscript tee.wsf C:
etstat.txt

If you want data appended to C:
etstat.txt instead, use a

  command line like this:

    netstat | cscript tee.wsf C:
etstat.txt /A

If you want to also write to C:data0218.txt, do this:

    netstat | cscript tee.wsf C:
etstat.txt C:data0218.txt

]]>






"path to one or more files to which the standard input data should be sent."

  many="true" required="1"/>