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

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

 

Предмет, раскрываемый здесь, относится к средам командной строки, и, в особенности, к обработке команд в среде командной строки.

УРОВЕНЬ ТЕХНИКИ

В среде командной строки интерфейс командной строки позволяет пользователю непосредственно выполнить задачу, вводя команду. Например, интерфейс командной строки может быть вызван так, чтобы показать окно, которое отображает приглашение (например, «C:\>»). Пользователь может напечатать команду, такую как «dir», в приглашении для выполнения команды. Несколько команд могут быть вместе сведены в конвейер (совокупность команд, выполняемых последовательно, где результат одной может быть входными условиями для следующей) для выполнения более сложной задачи. Обычным для этих конвейерных команд являются наличие очень сложных инструкций командной строки.

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

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 иллюстрирует примерное компьютерное устройство, которое может использовать примерную среду административной сервисной программы.

Фиг.2 является блок-схемой, в общем иллюстрирующей краткий обзор примерной оболочки административной сервисной программы для существующей среды административной сервисной программы.

Фиг.3 является блок-схемой, иллюстрирующей компоненты в специфических для хоста компонентах оболочки административной сервисной программы, показанной на фиг.2.

Фиг.4 является блок-схемой, иллюстрирующей компоненты в компоненте механизма ядра оболочки административной сервисной программы, показанной на фиг.2.

Фиг.5 является одной примерной структурой данных для определения cmdlet, подходящей для использования в административной сервисной программе, показанной на фиг.2.

Фиг.6 является примерной структурой данных для определения исходного типа команды, из которого получен cmdlet, показанный на фиг.5.

Фиг.7 является другой примерной структурой данных для определения cmdlet, подходящей для использования в административной сервисной программе, показанной на фиг.2.

Фиг.8 является логической блок-схемой, иллюстрирующей примерный процесс для обработки хоста, который осуществляется в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.9 является логической блок-схемой, иллюстрирующей примерный процесс для обработки ввода, который выполнен в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.10 является логической блок-схемой, иллюстрирующей процесс для обработки сценариев, подходящих для использования в процессе обработки ввода, показанного на фиг.9.

Фиг.11 является логической блок-схемой, иллюстрирующей процесс предварительной обработки сценария, подходящего для использования в процессе обработки сценария, показанного на фиг.10.

Фиг.12 является логической блок-схемой, иллюстрирующей процесс для применения ограничений, подходящих для использования в процессе обработки сценария, показанного на фиг.10.

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

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

Фиг.15 является логической блок-схемой, иллюстрирующей примерный процесс для создания экземпляра cmdlet, подходящего для использования в обработке командных строк, показанных на фиг.14.

Фиг.16 является логической блок-схемой, иллюстрирующей примерный процесс для заполнения свойств cmdlet, подходящего для использования в обработке команд, показанной на фиг.14.

Фиг.17 является логической блок-схемой, иллюстрирующей примерный процесс для выполнения cmdlet, подходящего для использования в обработке команд, показанной на фиг.14.

Фиг.18 является функциональной блок-схемой примерного устройства управления расширенного типа, подходящего для использования в оболочке административной сервисной программы, показанной на фиг.2.

Фиг.19 графически изображает примерные последовательности для обработки вывода cmdlets в конвейере.

Фиг.20 иллюстрирует примерную обработку, выполненную одной из обработок вывода cmdlets, показанной на фиг.19.

Фиг.21 графически изображает примерную структуру для отображения информации, доступной при обработке на фиг.20.

Фиг.22 является таблицей, показывающей список примерного синтаксиса для примерной обработки вывода cmdlets.

Фиг.23 иллюстрирует результаты, представленные выводом/консолью cmdlet, используя различные конвейерные последовательности для обработки вывода cmdlets.

РАСКРЫТИЕ

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

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

Следующее подробное описание разделено на несколько разделов. Первый раздел описывает примерную компьютерную среду, в которой может работать среда административной сервисной программы. Второй раздел описывает примерную оболочку для административной сервисной программы. Последующие разделы описывают индивидуальные компоненты примерной оболочки и функционирование этих компонентов. Например, раздел «Примерный процесс для выполнения Cmdlet», вместе с фиг.6, описывает примерный механизм для предоставления расширенных функциональных возможностей инструкциям командной строки.

Примерная компьютерная среда

Фиг.1 иллюстрирует примерное компьютерное устройство, которое может использоваться в примерной среде административной сервисной программы. В самой базовой конфигурации компьютерное устройство 100 обычно включает, по меньшей мере, один процессорный модуль 102 и системную память 104. В зависимости от точной конфигурации и типа компьютерного устройства, системная память 104 может быть энергозависимой (типа оперативной памяти (RAM)), энергонезависимой (типа постоянной памяти (ROM), флэш-памяти, и т.д.) или некоторая их комбинации. Системная память 104 обычно включает операционную систему 105, один или более программных модулей 106, и может включать программные данные 107. Операционная система 106 включает компонентно-ориентированную оболочку 120, которая поддерживает компоненты (включая свойства и события), объекты, наследование, полиморфизм, отражение, и обеспечивает объектно-ориентированный, основанный на использовании компонентов прикладной программный интерфейс (API), такой как NET™ Framework, созданный Microsoft Corporation, Redmond, WA. Операционная система 105 также включает оболочку 200 административной сервисной программы, которая взаимодействует с основанной на использовании компонентов оболочкой 120 для поддержки разработки административных инструментальных средств (не показанных здесь). Эта основная конфигурация проиллюстрирована на фиг.1 этими компонентами в пределах пунктирной линии 108.

Компьютерное устройство 100 может иметь дополнительные особенности или функциональные возможности. Например, компьютерное устройство 100 может также включает дополнительные устройства хранения данных (сменные и/или несменные), такие как, например, магнитные диски, оптические диски или ленты. Такое дополнительное устройство хранения проиллюстрировано на фиг.1 сменной памятью 109 и несменной памятью 110. Компьютерные носители данных могут включить энергозависимые и энергонезависимые, сменные и несменные носители, реализующие любой способ или технологию для хранения информации, такой как читаемые компьютером инструкции, структуры данных, программные модули, или другие данные. Системная память 104, сменная память 109 и несменная память 110 все являются примерами компьютерных носителей данных. Компьютерные носители данных включают, но не ограничены этим, оперативную память, ROM, RAM, EEPROM, флэш-память или другую технологию памяти, CD-ROM, цифровые универсальные диски (DVD) или другую оптическую память, магнитные кассеты, магнитную ленту, магнитную память на диске или другие магнитные запоминающие устройства, или любые другие носители информации, которые могут использоваться для хранения требуемой информации, и к которой можно обратиться компьютерным устройством 100. Любые такие компьютерные носители данных могут быть частью устройства 100. Компьютерное устройство 100 может также иметь устройство(а) ввода данных 112, такое как клавиатура, мышь, перо, устройства голосового ввода данных, сенсорное устройство ввода данных, и т.д. Устройство(а) вывода 114, такое как дисплей, динамики, принтер, и т.д. также может быть включено. Эти устройства хорошо известны в данной области техники и нет необходимости обсуждать их здесь подробно.

Компьютерное устройство 100 может также содержать коммуникационные подключения 116, которые позволяют устройству связываться с другими компьютерными устройствами 118, например по сети. Коммуникационные подключения 116 являются одним из примеров коммуникационных носителей информации. Коммуникационные носители информации могут обычно воплощаться читаемыми компьютером инструкциями, структурами данных, программными модулями, или другими данными в модулируемом сигнале данных, типа несущей или другом транспортном механизме, и включают любые доставляющие информационные носители. Термин «модулированный сигнал данных» означает сигнал, который имеет одну или более из своих характеристик установленной или измененной таким способом, чтобы кодировать информацию в сигнале. В качестве примера, но не ограничения, коммуникационные носители включают проводные носители типа проводной сети или прямого сетевого подключения, и беспроводные носители, типа акустических, ради инфракрасных и других беспроводных носителей информации. Термин «читаемые компьютером носители», используемый здесь, включает и носитель данных и коммуникационный носители.

Примерная оболочка административной сервисной программы

Фиг.2 является блок-схемой, в общем иллюстрирующей краткий обзор примерной оболочки 200 административной сервисной программы. Оболочка 200 административной сервисной программы включает один или более хост-компонентов 202, хост-специфичные компоненты 204, хост-независимые компоненты 206, и компоненты обработчика 208. Хост-независимые компоненты 206 могут связываться с каждым из других компонентов (то есть хост-компонентами 202, хост-специфичными компонентами 204, хост-независимыит компонентами 206 и компонентами обработчика 208). Каждый из этих компонентов кратко описан ниже и описан в деталях, когда это необходимо, в последующих разделах.

Хост-компоненты

Хост-компоненты 202 включают одну или более хост-программ (например, хост-программы 210-214), которые открывают возможности автоматизации для связанного приложения пользователю или другим программам. Каждая хост-программа 210-214 может открыть эти возможности автоматизации в своем собственном специфическом стиле, например через командную строку, графический интерфейс пользователя (GUI), интерфейс распознавания речи, прикладной программный интерфейс (API), язык сценариев, веб-сервис (служба, работающая через стандартный протокол интернета), и т.п. Однако каждая из хост-программ 210-214 открывает одну или более возможностей автоматизации через механизм, предоставляемый оболочкой административной сервисной программы.

В этом примере механизм использует cmdlets к плоскости возможностей административной сервисной программы для пользователя связанной хост-программы 210-214. Кроме того, механизм использует набор интерфейсов, сделанных доступными хостом, встроенным в среду административной сервисной программы в приложении, связанном с соответствующей хост-программой 210-214. Во время следующего обсуждения, термин «cmdlet» используется для ссылки на команды, которые используются в примерной среде административной сервисной программы, описанной со ссылкой на фиг.2-23.

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

Кроме того, в отличие от традиционных сред, у cmdlets нет необходимости выполняться независимыми программами. Напротив, cmdlets может выполняться в тех же самых процессах в оболочке административной сервисной программы. Это позволяет cmdlets обмениваться «живыми» объектами друг между другом. Эта способность обмениваться «живыми» объектами позволяет cmdlets непосредственно вызывать методы этих объектов. Детали для создания и использования cmdlets описаны в дополнительных деталях ниже.

В общем представлении каждая хост-программа 210-214 управляет взаимодействиями между пользователем и другими компонентами в оболочке административной сервисной программы. Эти взаимодействия могут включить подсказки для параметров, сообщения об ошибках и т.п. Как правило, каждая хост-программа 210-213 может обеспечить свой собственный набор определенных для хоста cmdlets (например, хост cmdlets 218). Например, если хост-программа является программой электронной почты, хост-программа может предоставить хост cmdlets, который взаимодействует с почтовыми ящиками и сообщениями. Даже притом, что фиг.2 иллюстрирует хост-программы 210-214, специалист в данной области техники оценит, что хост-компоненты 202 могут включать другие хост-программы, связанные с существующим или вновь созданными приложениями. Эти другие хост-программы также встраивают функциональные возможности, предоставленные средой административной сервисной программы в их связанном приложении. Обработка, обеспеченная хост-программой, описывается подробно ниже в связи с фиг.8.

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

В другом примере, хост-программа может быть интерактивной оболочкой командной строки (то есть хост-программа 212). Интерактивная оболочка командной строки может позволить метаданным 216 оболочки быть введенными в командную строку для влияния на обработку командной строки.

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

В дополнение к этим примерам, третьи стороны могут добавить свои собственные хост-компоненты, создавая интерфейсы «третьей стороны» или «поставщика» и предоставить cmdlets, которые используются с их хост-программой или другими хост-программами. Интерфейс поставщика открывает приложение или инфраструктуру так, чтобы приложение или инфраструктура могли управляться оболочкой административной сервисной программы. Поставщик cmdlets обеспечивает автоматизацию для навигации, диагностики, конфигурации, жизненного цикла, операций и т.п. Поставщик cmdlets демонстрирует полиморфное поведение cmdlet на полностью гетерогенном наборе хранилищ данных. Среда административной сервисной программы оперирует на поставщике cmdlets с тем же самым приоритетом, что и другие классы cmdlet. Поставщик cmdlet создается, используя те же самые механизмы, что и другие cmdlets. Поставщик cmdlets открывает определенные функциональные возможности приложения или инфраструктуры оболочке административной сервисной программы. Таким образом, с помощью cmdlets, разработчикам продукта требуется только создать один хост-компонент, который позволит их продукту работать со многими административными сервисными программами. Например, с примерной средой административной сервисной программы, справочные меню графического интерфейса пользователя системного уровня могут быть интегрированы и перенесены на существующие приложения.

Хост-специфичные компоненты

Хост-специфичные компоненты 204 включают совокупность служб, которые компьютерные системы (например, компьютерное устройство 100 на фиг.1) используют для изолирования оболочки административной сервисной программы от специфичной платформы, на которой выполняется оболочка. Таким образом, есть набор хост-специфичных компонентов для каждого типа платформ. Хост-специфичные компоненты позволяют пользователям использовать те же самые административные сервисные программы на различных операционных системах.

Обратимся к фиг.3, на которой хост-специфичные компоненты 204 могут включать компоненту 302 доступа к intellisense(технология отображения справочных ссылок по мере того, как печатается текст, без необходимости выхода из редактора)/метаданным, компонент 304 справки cmdlet, компонент 306 конфигурации/регистрации, компонент 308 установки cmdlet, и компонент 309 интерфейса вывода. Компоненты 302-308 взаимодействует с менеджером 312 хранилища базы данных, связанным с хранилищем 314 базы данных. Синтаксический анализатор 220 и механизм 222 сценариев взаимодействуют с компонентой 302 доступа к intellisense/метаданным. Механизм 224 ядра взаимодействует с компонентом 304 справки cmdlet, компонентом 306 конфигурации/регистрации cmdlet, компонентом установки 308, и компонентом 309 интерфейса вывода. Компонент 309 интерфейса вывода включает интерфейсы, предоставленные хостом для cmdlets. Эти cmdlets вывода могут вызывать объект вывода хоста для выполнения отображения. Хост-специфичные компоненты 204 могут также включать компонент 310 регистрации логов/аудита, который механизм 224 ядра использует для взаимодействия с хост-специфичной (то есть платформо-специфичной) службой, которая обеспечивают возможности регистрацию лога и аудита.

В одной примерной оболочке административной сервисной программы, компонента 302 доступа к intellisense/метаданным обеспечивает автозавершение команд, параметров, и значений параметра. Компонент 304 справки cmdlet обеспечивает настроенную систему справки, основанную на хост-интерфейсе пользователя.

Компоненты обработчика

Вернемся вновь к фиг.2, на котором компоненты обработчика 208 включают традиционные утилиты 230, управляющие cmdlets 232, неуправляющие cmdlets 234, удаленные cmdlets 236, и интерфейс 238 веб-сервиса. Управляющие cmdlets 232 (также называемые платформенными cmdlets) включают cmdlets, которые заращивают или манипулируют информацией о конфигурации, связанной с компьютерным устройством. Поскольку управляющие cmdlets 232 манипулируют информацией системного типа, они являются зависимыми от специфической платформы. Однако каждая платформа обычно имеет управляющие cmdlets 232, которые обеспечивают подобные действия, как управляющие cmdlets 232 на других платформах. Например, каждая платформа поддерживает управляющие cmdlets 232, которые получают и устанавливают системные административные атрибуты (например, получить/обработать, установить/IPAddress). Хост-независимые компоненты 206 взаимодействуют с управляющими cmdlets через объекты cmdlet, сгенерированные в хост-независимых компонентах 206. Примерные структуры данных для объектов cmdlets будут описаны подробно ниже в связи с фиг.5-7.

Неуправляющие cmdlets 234 (иногда называемые как базовые cmdlets) включают такие cmdlets, которые выполняют группировку, сортировку, фильтрацию, и выполняют другую обработку на объектах, предоставленных управляющих cmdlets 232. Неуправляющие cmdlets 234 могут также включать cmdlets для форматирования и вывода данных, связанных с конвейерными объектами. Примерный механизм для обеспечения вывода данных управляемых командной строкой описывается ниже в связи с фиг.19-23. Неуправляющие cmdlets 234 могут быть одними и теме же на каждой платформе и предоставлять набор утилит для взаимодействия с хост-независимыми компонентами 206 через объекты cmdlet. Взаимодействия между неуправляющими cmdlets 234 и хост-специфичными компонентами 206 позволяют отражение на объектах и позволяют обрабатывать на отраженных объектах, в не зависимости от их (объекта) типа. Таким образом, эти утилиты позволяют разработчикам написать неуправляющие cmdlets однажды и затем применять эти неуправляющие cmdlets во всех классах объектов, поддерживаемых на компьютерной системе. В прошлом разработчики должны были сначала осмыслить формат данных, который должен был быть обработан, а затем написать приложение для обработки только этих данных. Как следствие, традиционные приложения могли обработать данные только очень ограниченного объема. Один примерный механизм для обработки объектов, независимо от их типа, описан ниже в связи с фиг.18.

Традиционные утилиты 230 включают существующие исполняемые программы, такие как исполняемые программы под Win32, которые запускаются под cmd.exe. Каждая традиционная утилита 230 взаимодействует с оболочкой административной сервисной программы использования текстовые потоки (то есть stdin (стандартный поток ввода) и stdout (стандартный поток вывода)), которые являются типом объекта в объектной оболочке. Поскольку традиционные утилиты 230 используют текстовые потоки, операции на основе отражения, предоставляемые оболочкой административной сервисной программы, являются недоступными. Традиционные утилиты 230 выполняются в процессе, отличном от оболочки административной сервисной программы. Хотя и не показанные здесь, другие cmdlets могут также работать вне процесса.

Удаленные cmdlets 236, в комбинации с интерфейсом 238 веб-сервиса, обеспечивают удаленные механизмы для доступа к интерактивным и программируемым средам административной сервисной программы на других компьютерных устройствах с помощью коммуникационных носителей, таких как интернет или интранет (например, интернет/интранет 240, показанный на фиг.2). В одной примерной оболочке административной сервисной программы удаленные механизмы поддерживают объединенные службы, которые зависят от инфраструктуры, которая охватывает множество независимых управляемых доменов. Удаленный механизм позволяет сценариям выполняться на удаленных компьютерных устройствах. Сценарии могут быть запущены на отдельной или на множестве удаленных систем. Результаты сценариев могут быть обработаны по завершению каждого отдельного сценария, или результаты могут быть соединены и обработаны совместно после того, как все сценарии на различных компьютерных устройствах завершаться.

Например, веб-сервис 214, показанный как один из хост-компонентов 202, может быть удаленным агентом. Удаленный агент передает представление запроса удаленной команды синтаксическому анализатору и оболочке административной сервисной программы на целевой системе. Удаленный cmdlets служит удаленным клиентом, обеспечивающим доступ к удаленному агенту. Удаленный агент и удаленный cmdlets взаимодействуют через анализируемый поток. Этот анализируемый поток может быть защищен на уровне протокола, или дополнительный cmdlets может использоваться для шифрования и затем расшифровки анализируемого потока.

Хост-независимые компоненты

Хост-независимые компоненты 206 включают синтаксический анализатор 220, механизм 222 сценариев и механизм 224 ядра. Хост-независимые компоненты 206 предоставляют механизмы и службы группе множества cmdlets, координирующих работу cmdlets, и координирующих взаимодействие других ресурсов, сеансов и заданий с cmdlets.

Примерный синтаксический анализатор

Синтаксический анализатор 220 предоставляет механизмы для получения входных запросов от различных хост-программ и отображения входных запросов на единообразные объекты cmdlet, которые используются всюду в оболочке административной сервисной программы, например в механизме 224 ядра. Кроме того, синтаксический анализатор 220 может выполнить обработку данных, основываясь на полученном вводе. Один примерный способ для выполнения обработки данных, основываясь на вводе, описывается ниже в связи с фиг.12. Синтаксический анализатор 220 данной оболочки административной сервисной программы обеспечивает возможность легко открыть различные языки или синтаксис пользователям для одних и тех же возможностей. Например, поскольку синтаксический анализатор 220 отвечает за интерпретацию входных запросов, изменение в коде в синтаксическом анализаторе 220, который затрагивает ожидаемый входной синтаксис, по существу затронет каждого пользователя оболочки административной сервисной программы. Поэтому системные администраторы могут предоставить различные синтаксические анализаторы на различных компьютерных устройствах, которые поддерживают различный синтаксис. Однако каждый пользователь, работающий с одним и тем же синтаксическим анализатором, будет иметь опыт в непротиворечивом синтаксисе для каждого cmdlet. Напротив, в традиционных средах каждая команда реализовывала бы свой собственный синтаксис. Таким образом, с тысячами команд, каждая среда поддерживает несколько различных синтаксисов, многие из которых, обычно, противоречат друг другу.

Примерный механизм сценариев

Механизм 222 сценария предоставляет механизмы и службы для связи множества cmdlets вместе, используя сценарий. Сценарий является соединением частей командных строк, которые совместно используют состояние сеанса при строгих правилах наследования. Множество командных строк в сценарии могут быть выполнены или синхронно или асинхронно, основываясь на синтаксисе, переданном во входном запросе. Механизм 222 сценария имеет возможность обрабатывать управляющие структуры, такие как циклы и условные операторы, и обрабатывать переменные в сценарии. Механизм сценария также управляет состоянием сеанса и дает cmdlets доступ к данным сеанса, основываясь на политике (не показанной здесь).

Примерный механизм ядра

Механизм 224 ядра ответственен за обработку cmdlets, идентифицированных синтаксическим анализатором 220. Обратимся к фиг.4, на которой проиллюстрирован примерный механизм 224 ядра оболочки 200 административной сервисной программы. Примерный механизм 224 ядра включает конвейерный процессор 402, загрузчик 404, процессор 406 метаданных, обработчик 408 ошибок и событий, менеджер сеанса 410 и менеджер 412 расширенного типа.

Примерный обработчик метаданных

Обработчик 406 метаданных сконфигурирован для обращения и сохраненным метаданным в хранилище метаданных, таком как хранилище 314 базы данных, показанное на фиг.3. Метаданные могут быть переданы через командную строку, внутри определения класса cmdlet, и т.п. Различные компоненты оболочки 200 административной сервисной программы могут запросить метаданных при выполнении своей обработки. Например, синтаксический анализатор 202 может запросить метаданные для проверки правильности параметров, переданных в командной строке.

Примерный обработчик ошибок и событий

Обработчик 408 ошибок и событий предоставляет объект ошибки для хранения информации о каждом возникновении ошибки во время обработки командной строки. Для дополнительной информации о одном специфическом обработчике ошибок и событий, который наиболее подходит для представленной оболочки административной сервисной программы, требуется обратится к заявке на патент США № _____/ и патенту США № _____, озаглавленных «System and Method for Persisting Error information in a Command Line Environment», который принадлежит тому же самому правопреемнику, что и данное изобретение, и включен сюда по ссылке.

Примерный менеджер сеанса

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

Примерный конвейерный обработчик и загрузчик

Загрузчик 404 сконфигурирован для загрузки каждого cmdlet в память для того, чтобы конвейерный процессор 402 выполнил cmdlet. Конвейерный процессор 402 включает обработчик 420 cmdlet и менеджер 422 cmdlet. Обработчик 420 cmdlet обеспечивает диспетчеризацию индивидуальных cmdlets. Если cmdlet требует выполнения на удаленной, или наборе удаленных машин, процессор 420 cmdlet координирует выполнение вместе с удаленным cmdlet 236 показанным на фиг.2. Менеджер 422 cmdlet обрабатывает выполнение агрегирования (механизм многократного использования при наследовании одним объектом методов другого объекта) cmdlets. Менеджер 422 cmdlet, процессор 420 cmdlet, и механизм 222 сценариев (фиг.2) связываются друг с другом для выполнения обработки ввода, полученного от хост-программы 210-214. Взаимодействие может быть рекурсивным по своей природе. Например, если хост-программа предоставляет сценарий, сценарий может вызвать менеджера 422 cmdlet для того, чтобы выполнить cmdlet, который сам может быть сценарием. Сценарий может тогда быть выполненным механизмом 222 сценария. Один примерный поток обработки для базового механизма описывается подробно ниже при рассмотрении фиг.14.

Примерный менеджер расширенных типов

Как упомянуто выше, оболочка административной сервисной программы предоставляет набор утилит, который позволяет отражение на объектах и позволяет осуществлять обработку на отраженных объектах, независимо от их (объектов) типа. Оболочка 200 административной сервисной программы взаимодействует с оболочкой компонентов на компьютерной системе (оболочка компонентов 120 на фиг.1) для выполнения этого отражения. Как может оценить специалист в данной области техники, отражение обеспечивает способность сделать запрос объекта и получить тип для объекта, и затем отразить на различные объекты и свойства, связанные с тем же типом объекта для того, чтобы получить другие объекты и/или желаемое значение.

Даже при том, что отражение обеспечивает оболочке 200 административной сервисной программы значительное количество информации относительно объектов, изобретатели осознают, что отражения фокусируются на типе объекта. Например, когда база данных datatable отражена, возвращаемой информацией является то, что datatable имеет два свойства: свойство столбца и свойство строки. Эти два свойства не обеспечивают достаточных деталей относительно «объектов» в datatable. Подобные проблем возникают, когда отражение используется на расширяемом языке разметки (XML) и других объектах.

Таким образом, изобретатели придумали менеджер 412 расширенного типа, который фокусируется на использование типа. Для этого менеджера расширенного типа, тип объекта не важен. Вместо этого, менеджер расширенного типа интересуется тем, может ли объект использоваться для получения требуемой информации. Продолжая пример вышеупомянутой datatable, изобретатели осознают, что знание того, что datatable имеет свойство столбца и свойство строки, не особенно интересно, но осознают то, что один столбец содержит информацию, представляющую интерес. Фокусируясь на использовании, можно было связать каждую строку с «объектом» и связать каждый столбец со «свойством» этого «объекта». Таким образом, менеджер 412 расширенного типа обеспечивает механизм для создания «объектов» из любого типа предназначенного для точного синтаксического анализа ввода. Таким образом, менеджер 412 расширенного типа добавляет возможности отражения, предоставленные компонентно-ориентированной оболочкой 120, и расширяет «отражение» на любой тип предназначенного для точного синтаксического анализа ввода.

В общих чертах, менеджер расширенного типа сконфигурирован для обращения к точно предназначенному для синтаксического анализа вводу (не показанному здесь) и корреляции предназначенному для точного синтаксического анализа ввода с требуемым типом данных. Менеджер 412 расширенного типа после этого обеспечивает требуемую информацию требуемой компоненте, такой как конвейерный обработчик 402 или синтаксический анализатор 220. В следующем обсуждении, предназначенный для точного синтаксического анализа ввод определен как ввод, в котором свойства и значения могут различаться. Некоторые примеры предназначенного для точного синтаксического анализа ввода включает ввод Windows Management Instrument (WMI), ввод ActiveX Data Object (ADO), ввод расширяемого языка разметки (XML), и объектный ввод, такой как объекты.NET. Другой предназначенный для точного синтаксического анализа ввод может включить форматы данных третьих сторон.

Обратимся кратко к фиг.18, показывающей функциональную блок-схему примерного менеджера расширенного типа для использования в оболочке административной сервисной программы. Для целей объяснения, функциональные возможности (обозначенные номером «3» в круге) предоставляемые менеджером расширенного типа, противопоставлены функциональными возможностями, предоставляемыми традиционной тесно связанной системой (обозначенные номером «1» в круге) и функциональные возможности, предоставляемые системой отражения (обозначенные номером «2» в круге). В традиционной тесно связанной системе вызывающий 1802 в приложении непосредственно обращается к информации (например, свойствам P1 и P2, методам М1 и M2) в объекте A. Как упомянуто выше, вызывающий 1802 должен знать, априори, свойства (например, свойства P1 и P2) и методы (например, методы М1 и M2), предоставляемые объектом A, во времени компиляции. В системе отражения, универсальный код 1808 (не зависящий от любого типа данных) делает запрос к системе 1808, который выполняет отражение 1810 на требуемом объекте, и возвращает информацию (например, свойства P1 и P2, методы М1 и M2) об объекте (например, объекте A) универсальному коду 1820. Хотя это и не показано в объекте A, возвращаемая информация может включать дополнительную информацию, типа поставщика, файла, даты, и т.п. Таким образом, через отражение, универсальный код 1820 получает, по меньшей мере, ту же самую информацию, которую обеспечивает точно связанная система. Система отражения также позволяет вызывающему 1802 запросить систему и получить дополнительную информацию без любого априорного знания параметров.

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

Однако с представленным менеджером расширенного типа, новые типы данных могут быть включены в операционную систему. С менеджером 1822 расширенного типа, универсальный код 1820 может отражаться на требуемый объект для получения расширенных типов данных (например, объект A') предоставленный различными внешними источниками, типа объектов третьих сторон (например, объект A' и B), семантическая сеть 1832, служба онтологии 1834 и т.п. Как показано, объект третьей стороны может расширять существующий объект (например, объект A') или может создать полностью новый объект (например, объект B).

Каждый из этих внешних источников может регистрировать свою уникальную структуру в метаданных 1840 типов и может предоставить код 1842. Когда к объекту делается запрос, менеджер расширенного типа делает обзор метаданных 1840 типов для того, чтобы определить, был ли объект зарегистрирован. Если объект не зарегистрирован в метаданных 1840 типов, отражение выполнено. Иначе выполнено расширенное отражение. Код 1842 возвращает дополнительные свойства и методы, связанные с типом, над которым производят отражение. Например, если входной тип является XML, код 1842 может включить файл описания, который описывает способ, которым XML используется, для создания объектов из XML документа. Таким образом, метаданные 1840 типа, которые описывают, как менеджер 412 расширенного типа должен запрашивать различные типы предназначенному для точного синтаксического анализа ввода (например, объектов третьей стороны A' и B, семантической сети 1832) для получения желаемых свойств для того, чтобы создать объект для этого определенного входного типа и кода 1842, предоставляют команды для получения этих желаемых свойств. В результате менеджер 412 расширенного типа обеспечивает уровень симметричности, который позволяет «отражение» на всех типах объектов.

В дополнение к предоставлению расширенных типов, менеджер 412 расширенного типа предоставляет дополнительные механизмы запроса, такие как механизм свойства пути, ключевой механизм, механизм сравнения, механизм преобразования, механизм универсализации, механизм установки свойства, механизма отношений, и т.п. Каждый из этих механизмов запроса, описываемых ниже в разделе «Примерный менеджер обработки расширенных типов», обеспечивает гибкость системным администраторам при вводе командных строк. Могут использоваться различные методики для осуществления семантики для менеджера расширенного типа. Три методики описаны ниже. Однако специалисты в данной области техники оценят, что разновидности этих методик могут использоваться, не отступая от объема данного изобретения.

В одной методике может быть предоставлен ряд классов, имеющих статические методы (например, getproperty()). Объект является вводом в статический метод (например, getproperty(объект)), и статический метод возвращает набор результатов. Для другой методики операционная среда обертывает объект адаптером. Таким образом, не предоставляется никакого ввода. Каждый образец адаптера имеет метод getproperty, который действует на обернутый объект и возвращает свойства для обернутого объекта. Следующее является псевдокодом, иллюстрирующим эту методику:

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

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

Вернемся снова к фиг.2, где, кратко говоря, оболочка 200 административной сервисной программы не полагается на командный процессор для координирования выполнение ввода команд пользователями, а скорее разбивает функциональные возможности на обработку частей (например, хост-независимых компонентов 206) и части пользовательского взаимодействия (например, через хост cmdlets). Кроме того, данная среда административной сервисной программы очень упрощает программирование административных сервисных программ, потому что код, требуемый для синтаксического анализа и проверки правильности данных, больше не включается в каждую команду, но, скорее, предоставляется компонентами (например, синтаксическим анализатором 220) в оболочке административной сервисной программы. Примерная обработка, выполненная в оболочке административной сервисной программы, описана ниже.

Примерные операции

Фиг.5-7 графически иллюстрируют примерные структуры данных, используемые в среде административной сервисной программы. Фиг.8-17 графически иллюстрируют примерные потоки обработки в среде административной сервисной программы. Специалист в данной области техники оценит, что некая обработка может быть выполнена компонентой, отличной от компоненты, описанной ниже, не отступая от объема данного изобретения. Перед описанием обработки, выполненной в компонентах оболочки административной сервисной программы, описаны примерные структуры данных, используемые в оболочке административной сервисной программы.

Примерные структуры данных для объектов cmdlet

Фиг.5 является примерной структурой данных для определения cmdlet, подходящего для использования в оболочке административной сервисной программы, показанной на фиг.2. После завершения, cmdlet может быть управляющей cmdlet, неуправляющей cmdlet, хостом cmdlet, поставщиком cmdlet, или подобное им. Следующее обсуждение описывает создание cmdlet относительно видения системного администратора (то есть поставщика cmdlet). Однако каждый тип cmdlet создается тем же самым способом и работает подобным образом. Cmdlet может быть написан на любом языке, типа C#. Кроме того, cmdlet может быть написан, используя язык сценариев или подобный ему. Когда административная среда инструмента работает с.NET Framework, cmdlet может быть объектом.NET.

Поставщик 500 cmdlet (в дальнейшем упоминаемый как cmdlet 500) является открытым классом, имеющим cmdlet имя класса (например, StopProcess 504). Cmdlet 500 происходит из cmdlet класса 506. Примерная структура данных на класс 506 cmdlet описана ниже при описании фиг.6. Каждый cmdlet 500 связан с командным атрибутом 502, который связывает имя (например, Stop/Process) с cmdlet 500. Имя зарегистрировано в среде административной сервисной программы. Как будет описано ниже, синтаксический анализатор смотрит в системный реестр cmdlet для идентификации cmdlet 500, когда командная строка, имеющая имя (например, Stop/Process), предоставлена как ввод в командной строке или в сценарии.

Cmdlet 500 связан с механизмом грамматики, который определяет грамматику для ожидаемых входных параметров для cmdlet. Механизм грамматики может быть непосредственно или косвенно связан с cmdlet. Например, cmdlet 500 иллюстрирует прямую ассоциацию грамматики. В этом cmdlet 500 объявлен один или более открытых параметров (например, ProcessName и PID 512). Объявление открытых параметров управляет синтаксическим анализом ввода объекта cmdlet 500. Альтернативно, описание параметров может появиться во внешнем источнике, таком как XML документа. Описание параметров в этом внешнем источнике тогда управляет синтаксическим анализом ввода объекта cmdlet.

Каждый открытый параметр 510, 512 может иметь один или более атрибутов (то есть директив), связанных с ним. Директивы могут быть от любой из следующих категорий: директива 521 семантического анализа, директива 522 проверки правильности данных, директива 523 генерации данных, директива 524 обработки, директива 525 кодирования, и директива 526 документирования. Директивы могут быть окружены квадратными скобками. Каждая директива описывает операцию, которая будет выполнена на следующем ожидаемом входном параметре. Некоторые из директив могут также быть применены на уровне класса, такие как директивы взаимодействия с пользователем. Директивы сохраняются в метаданных, связанных с cmdlet. Применение этих атрибутов описано ниже при описании фиг.12.

Эти атрибуты могут также затронуть совокупность параметров, объявленных в cmdlet. Один примерный процесс для заполнения этих параметров описан ниже при описании фиг.16. Базовый механизм может применить эти директивы для того, чтобы гарантировать соответствие. Cmdlet 500 включает первый метод (в дальнейшем упоминаемый как метод 530 StartProcessing) и второй метод 540 (в дальнейшем упоминаемый как метод 540 processRecord). Базовый механизм использует первый и второй методы 530, 540 для непосредственной обработки cmdlet 500, Например, первый метод 530 выполняется однажды и выполняет функции установки. Код 542 во втором методе 540 выполняется для каждого объекта (например, записи), который должен быть обработан cmdlet 500. Cmdlet 500 может также включать третий метод (не показанный здесь), который очищает после cmdlet 500.

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

Фиг.6 является примерной структурой 600 данных для того, чтобы определить базовый класс 602 cmdlet, из которого получен cmdlet, показанный на фиг.5. Базовый класс 602 cmdlet включает команды, которые предоставляют дополнительные функциональные возможности всякий раз, когда cmdlet включает инструкцию перехватчика, и соответствующий переключатель является вводом в командной строке или в сценарии (совместно называемые как командный ввод).

Примерная структура 600 данных включает параметры, типа логического параметра 610 verbose (озвучивание действий), whatif 620 (действие если), и confirm 630 (подтверждать). Как будет объяснено ниже, эти параметры соответствуют строкам, которые могут быть введены в командный ввод. Примерная структура 600 данных может также включать метод 640 защиты, который определяет, разрешена ли задача, которую требуют для выполнения.

Фиг.7 является другой примерной структурой 700 данных для определения cmdlet Короче говоря, структура 700 данных обеспечивает средство для того, чтобы ясно выразить контракт между оболочкой административной сервисной программы и cmdlet. Подобно структуре 500 данных, структура 700 данных является открытым классом, который происходит из cmdlet класса 704. Разработчик программы определяет cmdletDeclaration 702, которая связывает пару существительного/глагола, типа «получать/обрабатывать» и «формат/таблица», с cmdlet 700. Пара существительного/глагола регистрируется в среде административной сервисной программы. Глагол или существительное неявно могут присутствовать в имени cmdlet. Также, подобно структуре 500 данных, структура 700 данных может включать одно или более открытых членов (например, Name 7, Recurse 732), которые могут быть связаны с одной или более директив 520-526, описанных вместе со структурой 500 данных.

Однако в этой примерной структуре 700 данных каждый из ожидаемых входных параметров 730 и 732 связан со входным атрибутом 731 и 733 соответственно. Атрибуты ввода 731 и 733 определяют, что данные для его соответствующего параметра 730 и 732 должны быть получены из командной строки. Таким образом, в этой примерной структуре 700 данных нет никаких ожидаемых входных параметров, которые заполняются из конвейерного объекта, который выпущен другим cmdlet. Таким образом, структура 700 данных не отменяет первый метод (например, StartProcessing) или второй метод (например, ProcessRecord), которые предоставляются базовым классом cmdlet.

Структура 700 данных может также включать закрытый член 740, который не распознается как входной параметр. Закрытый член 740 может использоваться для сохранения данных, которые сгенерированы, основываясь на одной из директив.

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

Теперь будут описаны примерные потоки процесса в среде административной сервисной программы.

Примерный поток обработки хоста

Фиг.8 является логической блок-схемой, иллюстрирующей примерный процесс для обработки хоста, который производится в оболочке административной сервисной программы, показанной на фиг.2. Процесс 800 начинается в блоке 801, где запрос был получен, для инициирования среды административной сервисной программы для определенного приложения. Запрос может быть послан локально через ввод с клавиатуры, например выбора программной иконки, или дистанционно через интерфейс веб-сервиса другого компьютерного устройства. При любом сценарии обработка переходит к блоку 802.

В блоке 802, определенное приложение (например, хост-программа) на «целевом» компьютерном устройстве устанавливает его среду. Это включает определение, какие подмножества cmdlets (например, управляющие cmdlets 232, неуправляющие cmdlets 234, и хост cmdlets 218) сделать доступным пользователю. Как правило, хост-программа сделает все неуправляющие cmdlets 234 доступным, и также свой собственный хост cmdlets 218 доступным. Кроме того, хост-программа сделает подмножество управляющих cmdlets 234, таких как cmdlets, имеющих дело с процессами, диском, и т.п., доступным. Таким образом, как только хост-программа делает подмножества cmdlets доступными, оболочка административной сервисной программы фактически внедрена в соответствующее приложение. Обработка переходит к блоку 804.

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

В блоке 806 ввод передается к другим компонентам в оболочке административной сервисной программы для обработки. Хост-программа может отправить ввод непосредственно другим компонентам, таким как синтаксический анализатор. Альтернативно хост-программа может отправить ввод через один из его хостовых cmdlets. Хост cmndlet может преобразовать свой определенный тип ввода (например, голос) в тип ввода (например, текстовую строку, сценарий), который распознается оболочкой административной сервисной программы. Например, голосовой ввод может быть преобразован в сценарий или строку командной строки в зависимости от содержания голосового ввода. Поскольку каждая хост-программа ответственна за преобразование своего типа ввода к вводу, распознаваемому оболочкой административной сервисной программы, оболочка административной сервисной программы может принять ввод от любого числа различных хост-компонентов. Кроме того, оболочка административной сервисной программы обеспечивает богатый набор утилит, которые выполняют преобразования между типами данных, когда ввод отправлен через один из его cmdlets. Обработка, выполняемая над вводом другими компонентами, описана ниже вместе с описанием некоторых других чертежей. Обработка хоста переходит к решающему блоку 808.

В решающем блоке 808 определяется, был ли запрос получен для дополнительного ввода. Это может произойти, если один из других компонентов, ответственных за обработку ввода, нуждается в дополнительной информации от пользователя для того, чтобы завершить свою обработку. Например, пароль может требоваться для обращения к некоторым данным, может быть необходимо подтверждение определенных действий и т.п. Для некоторых типов хост-программ (например, голосовая почта), запрос, такой как этот, не может быть соответствующим. Таким образом, вместо того, чтобы запрашивать у пользователя дополнительную информацию, хост-программа может преобразовать в последовательную форму состояние, приостановить состояние и послать уведомление так, чтобы в более позднее время состояние могло быть восстановлено, и выполнение ввода было бы продолжено. В другой разновидности хост-программа может предоставить значение по умолчанию после предопределенного периода времени. Если запрос о дополнительном вводе получен, обработка вернется в цикле назад к блоку 804, где получен дополнительный ввод. Обработка тогда продолжится через блоки 806 и 808 так, как описано выше. Если никакой запрос на дополнительный ввод не получен, и ввод был обработан, обработка переходит к блоку 810.

В блоке 810 получаются результаты от других компонентов в оболочке административной сервисной программы. Результаты могут включать сообщения об ошибках, статус, и т.п. Результаты находятся в объектной форме, которая распознается и обрабатывается хостом cmdlet в оболочке административной сервисной программы. Как будет описано ниже, код, написанный для каждого хоста cmdlet, очень минимален. Таким образом, может быть отображен богатый набор вывода, не требуя огромных инвестиций в стоимость разработки. Обработка переходит к блоку 812.

В блоке 812 могут просматриваться результаты. Хост cmdlet преобразовывает результаты к стилю отображения, поддерживаемому хост-программой. Например, возвращенный объект может быть отображен в соответствии с программой графического интерфейса хоста, используя графическое описание, например иконки, barking dog, и т.п. Хост cmdlet обеспечивает заданный по умолчанию формат и вывод для данных. Заданный по умолчанию формат и вывод могут использовать примерный вывод, обрабатываемый cmdlets и описанный ниже при описании фиг.19-23. После того как результаты опционально отображены, обработка хоста закончена.

Примерный обрабатывающий поток для обработки ввода

Фиг.9 является логической блок-схемой, иллюстрирующая примерный процесс для обработки ввода, который выполняется в оболочке административной сервисной программы, показанной на фиг.2. Обработка начинается в блоке 901, где ввод был введен через хост-программу и отправлен другим компонентам в оболочке административной сервисной программы. Обработка переходит к блоку 902.

В блоке 902 получен ввод от хост-программы. В одной примерной оболочке административной сервисной программы ввод получает синтаксический анализатор, который декодирует ввод и направляет ввод для дальнейшей обработки. Обработка переходит к решающему блоку 904.

В решающем блоке 904 определяется, является ли ввод сценарием. Ввод может принять форму сценария или строки, представляющей командную строку (в дальнейшем называемая как «командная строка»). Командная строка может представлять собой один или более cmdlets, обрабатываемых конвейерно вместе. Даже при том, что оболочка административной сервисной программы поддерживает несколько различных хостов, каждый хост предоставляет ввод как сценарий или командную строку для обработки. Как будет показано ниже, взаимодействие между сценариями и командными строками рекурсивно по своей природе. Например, сценарий может иметь строку, которая вызывает cmdlet. Сам cmdlet может быть сценарием.

Таким образом, если ввод находится в форме сценария, в решающем блоке 904 обработка переходит к блоку 906, где выполняется обработка сценария. Иначе обработка переходит к блоку 908, где выполняется обработка командной строки. Как только обработка, выполненная блоке 906 или 908, закончена, обработка ввода закончена.

Примерная обработка сценариев

Фиг.10 является логической блок-схемой, иллюстрирующей процесс для обработки сценария, подходящий для использования в процессе для обработки ввода, показанного на фиг.9. Процесс начинается в блоке 1001, где ввод был идентифицирован как сценарий. Механизм сценария и синтаксический анализатор связываются друг с другом для выполнения следующих функций. Обработка переходит к блоку 1002.

В блоке 1002 выполняется предварительная обработка сценария. Кратко обратимся к фиг.11, показывающему логическую блок-схему, иллюстрирующую предварительную обработку 1100 сценария, подходящего для использования с процессом 1000 обработки сценария. Предварительная обработка сценария начинается в блоке 1101 и переходит к решающему блоку 1102.

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

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

В блоке 1106 из сценария извлекаются справка и документация и сохраняются в системном реестре. Вновь к этой информации могут обратиться позднее компоненты в оболочке административной сервисной программы. Сценарий теперь готов к обработке и возвращается к блоку 1104 на фиг.10.

Возвращаясь к решающему блоку 1102, где обработка переходит к решающему блоку 1108, если процесс решает, что имеется сценарий, выполнявшийся предварительно. В решающем блоке 1108 определяется, потерпел ли сценарий неудачу во время обработки. Эта информация может быть получена из системного реестра. Если сценарий не терпел неудачу, сценарий готов к обработке и возвращается к блоку 1004 на фиг.10.

Однако если сценарий потерпел неудачу, обработка переходит к блоку 1110. В блоке 1110 механизм сценария может уведомить пользователя через хост-программу, что сценарий предварительно терпел неудачу. Это уведомление позволит пользователю решить, продолжить ли сценарий или выйти из сценария. Как упоминалось выше при описании фиг.8, хост-программа может обработать этот запрос различными способами в зависимости от стиля ввода (например, голосового, командной строки). Как только дополнительный ввод будет получен от пользователя, сценарий или вернется к блоку 1004 на фиг.10 для обработки, или сценарий будет прерван.

Возвратимся к блоку 1004 на фиг.10, где получена строка от сценария. Обработка переходит к решающему блоку 1006. В решающем блоке 1006 определяется, включает ли строка какие-либо ограничения. Ограничение обнаруживается с помощью предопределенного начального символа (например, скобки «[«) и соответствующего конечного символа (например, закрывающая скобка «]»). Если строка включает ограничения, обработка переходит к блоку 1008.

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

В решающем блоке определяется, включает ли строка из сценария встроенные возможности. Встроенные возможности - это возможности, которые не выполняются основным механизмом. Встроенные возможности могут быть обработаны, используя cmdlets, или могут быть обработаны, используя другие механизмы, такие как встраиваемые функции (встраиваемые функции являются функциями, вызов которых при компиляции заменяется ее кодом). Если строка не имеет встроенных возможностей, обработка продолжается в решающем блоке 1014. Иначе обработка продолжается в блоке 1012.

В блоке 1012 обрабатываются встроенные возможности, представленные в строке сценария. Пример встроенных возможностей может включать выполнение управляющих структур, типа операторов «if», циклов «for», переключателей, и т.п. Встроенные возможности могут также включить инструкции присвоения для типа (например, a=3). Как только встроенные возможности будут обработаны, обработка переходит к решающему блоку 1014.

В решающем блоке 1014 определяется, включает ли строка сценария командную строку. Определение основывается на том, связаны ли данные строки с командной строкой, которая была зарегистрирована, и с синтаксисом потенциального вызова cmdlet. Как упоминалось выше, обработка командных строк и сценариев может быть рекурсивна по своей природе, потому что сценарии могут включать командные строки, и строки команды могут выполнить cmdlet, который непосредственно является сценарием. Если строка не включает командную строку, обработка продолжается в решающем блоке 1018. Иначе обработка продолжается в блоке 1016.

В блоке 1016 обрабатывается строка команды. Коротко говоря, обработка строки команды включает идентификацию класса cmdlet синтаксическим анализатором и передачу соответствующего cmdlet объекта в базовый механизм для выполнения. Командная строка может также включить конвейерную командную строку, которая разбирается на несколько индивидуальных объектов cmdlet и индивидуально обрабатывается базовым механизмом. Один примерный процесс для обработки командной строки описан ниже при описании фиг.14. Как только строка команды обработана, обработка переходит к решающему блоку 1018.

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

Примерный процесс для применения ограничения в блоке 1008 проиллюстрирован на фиг.12. Процесс начинается в блоке 1201, где ограничение обнаруживается в сценарии или в строке команды на командной строке. Когда ограничение находится в сценарии, ограничения и связанная конструкция могут находится на той же самой строке или на разных строках. Когда ограничение находится в строке команды, ограничение и связанная конструкция находятся перед концом индикатора строки (например, клавиши ввода). Обработка переходит к блоку 1202.

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

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

В блоке 1204 полученные ограничения сохраняются в метаданных для связанной конструкции. Связанная конструкция идентифицируется, когда возникает первая неатрибутированная лексема после одной или более атрибутированных лексем (лексемы, которые обозначают ограничения). Обработка переходит к блоку 1206.

В блоке 1206 всякий раз, когда в конструкции, в сценарии или в строке команды сталкиваются с ограничениями, определенными в метаданных и применимыми к конструкции. Ограничения могут включать тип данных, директивы 1210 предиката, директивы 1212 документирования, директивы 1214 синтаксического анализа, директивы 1216 генерации данных, директивы 1218 проверки правильности данных, и директивы 1220 обработки и кодирования объекта. Ограничения, определяющие типы данных, могут определить любой тип данных, поддерживаемый системой, на которой выполняется оболочка административной сервисной программы. Директивы 1210 предиката являются директивами, которые указывают, должна ли обработка произойти. Таким образом, директивы 1210 предиката гарантируют, что среда является корректной для выполнения. Например, сценарий может включить следующую директиву предиката:

[PredicateScript («isInstalled», «'ApplicationZ»)]

Директива предиката гарантирует, что правильное приложение установлено на компьютерном устройстве перед выполнением сценария. Как правило, переменные системной среды могут быть определены как директивы предиката. Примерные директивы из типов 1212-1220 директив проиллюстрированы в Таблицах 1-5. Обработка сценария после этого закончена.

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

[Integer][ValidationRange(3, 5)]$a=4.

Есть два ограничения, указанные через атрибутированные лексемы, обозначенные

«[]». Первая атрибутированная лексема указывает, что переменная имеет тип «integer», и вторая атрибутированная лексема указывает, что значение переменной $a должно быть между 3 и 5 включительно. Строка команды примера гарантирует, что если переменная $a будет назначена в последующей командной строке или строке, переменная $a будет проверена по этим двум ограничениям. Таким образом, следующие командные строки должны были бы каждая привести к ошибке:

$a = 231

$a = "apple"

$a = $(get/location).

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

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

Название	Описание
PrerequisiteMachineRoleAttribute	Сообщают оболочке, должен ли элемент использоваться только в некоторых машинных ролях (например, Файловом сервере, Почтовом сервер).
PrerequisiteUserRoleAttribute	Сообщает оболочке, должен ли элемент использоваться только в некоторых пользовательских ролях (например, Администратора домена, Оператор резервного копирования).
PrerequisiteScriptAttribute	Сообщает оболочке, в которой этот сценарий будет выполнятся, перед выполнением фактической команды или параметра. Может использоваться для проверки правильности параметра
PrerequisiteUITypeAttribute	Это используется для проверки доступности Интерфейса пользователя перед выполнением.
Таблица 1. Директивы применимости

Название	Описание
ParsingParameterPositionAttribute	Карты неквалифицированных параметров, основанных на позиции.
ParsingVariableLengthParameterList Attribute	Карты параметров, не имеющих атрибута ParsingParameterPosition.
ParsingDisallowInteractionAttribute	Определяет действие, когда число параметров меньше требуемого числа.
ParsingRequirelnteractionAttribute	Определяет, что параметры получены интерактивно.
ParsingHiddenElementAttribute	Делает параметр невидимым для конечного пользователя.
ParsmgMandatoryParameterAttribute	Определяет, что параметр требуется.
ParsingPasswordParameterAttribute	Требует специальной обработки параметра.
ParsingPromptStringAttribute	Определяет подсказку для параметра.
ParsingDefaultAnswerAttribute	Определяет заданный по умолчанию ответ для параметра.
ParsingDefaultAnswerScriptAttribute	Определяет действие, чтобы получить заданный по умолчанию ответ для параметра.
ParsingDefaultValueAttribute	Определяет значение по умолчанию для параметра.
ParsingDefaultValueScriptAttribute	Определяет действие, чтобы получить значение по умолчанию для параметров.
ParsingParameterMappingAttribute	Определяет путь к параметрам группы.
ParsingParameterDeclarationAttribute	Это определяет, что поле является параметром.
ParsingAllowPipelinemputAttribute	Определяет, что параметр может быть заполнен из конвейера.
Таблица 2. Директив руководства синтаксического анализа.

Название	Описание
DocumentNameAttribute	Предоставляет название для обращения к элементам для взаимодействия или справки.
DocumentShortDescriptionAttribute	Предоставляет краткое описание элемента.
DocumentLongDescriptionAttribute	Предоставляет детальное описание элемента.
DocumentExampleAttribute	Предоставляет пример элемента.
DocumentSeeAlsoAttribute	Предоставляет список связанных элементов.
DocumentSynopsisAttribute	Предоставляет документационную информацию для элемента.
Таблица 3. Директивы документирования

Название	Описание
ValidationRangeAttribute	Определяет, что параметр должен быть в пределах некоторого диапазона.
ValidatiottSetAttribute	Определяет, что параметр должен быть в пределах некоторой совокупности.
ValidationPatternAttribute	Определяет, что параметр должен соответствовать некоторому образцу.
ValidationLengthAttribute	Определяет, что строки должны быть в пределах диапазона размера.
ValidationTypeAttribute	Определяет, что параметр должен быть некоторого типа.
ValidatiottCountArtributue	Определяет, что входные элементы должны быть в определенном количестве.
ValidationFileAttribute	Определяет некоторые свойства для файла.
ValidationFileAttributesAttribute	Определяет некоторые свойства для файла.
ValidationFileSizeAttribute	Определяет, что файлы должны быть в пределах указанного диапазона.
ValidationNetworkAttribute	Определяет, что данный сетевой объект поддерживает некоторые свойства.
ValidationScriptAttribute	Определяет условия для оценки перед использованием элемента.
ValidationMethodAttribute	Определяет условия для оценки перед использованием элемента.
Таблица 4. Директивы проверки правильности данных

Название	Описание
ProcessingTrimStringAttribute	Определяет предел размера для строк.
ProcessingTrimCollectionAttribute	Определяет предел размера для совокупности.
EncodingTypeCoercionAttribute	Определяет тип, которым объекты должны быть закодированы.
xpansionWildcardsAttribute	Предоставляет механизм для разрешения универсализации.
Таблица 5. Директивы обработка и кодирования.

Когда примерная оболочка административной сервисной программы используется в.NET ™ Framework, каждая категория имеет базовый класс, который получен из базового класса категории (например, CmdAttribute). Базовый класс категории происходит от класса System.Attribute. Каждая категория имеет предопределенную функцию (например, attrib.func()), которая вызывается синтаксическим анализатором во время обработки категории. Автор сценария может создать специальную категорию, которая получена из класса специальной категории (например, CmdCustomAttribute). Автор сценария может также расширить класс существующей категории порождением класса директивы от базового класса категории для этой категории и переопределяя предопределенную функцию в их реализации. Автор сценария может также переопределить директивы и добавить новые директивы к предопределенному набору директив.

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

Примерная обработка командных строк

Теперь опишем один примерный процесс для обработки командной строки. Фиг.13 является функциональной блок-схемой, графически иллюстрирующей обработку командной строки 1350 с помощью синтаксического анализатора 220 и базового механизма 224 в оболочке административной сервисной программы, показанной на фиг.2. Примерная командная строка 1350 конвейерно отрабатывает несколько команд (то есть команду 1360 обработки, команды 1362 where, команда 1364 сортировки, и команда 1366 таблицы). Командная строка 1350 может передать входные параметры для любой из команд (например, «handlecount>400» передаются к команде 1362 «where»). Обратим внимание, что команда 1360 обработки не имеет никаких связанных входных параметров.

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

Например, в среде UNIX, команда «ls» и команда «ps» имеют много несогласованностей между ними. В то время как обе принимают опцию «-w», опция «-w» используется командой «ls» для того, чтобы обозначить ширину страницы, в то время как опция «-w», используется командой «ps» для обозначения ширины вывода на печать (в сущности, игнорируя ширину страницы). Справочные страницы, связанные с «ls» и «ps» командами, имеют также несколько несогласованностей, таких как наличие опций, выделенных в одной, но не в другой, сортировка вариантов в алфавитном порядке в одном, но не другом, требование некоторых вариантов иметь черточки, а в некоторых - нет.

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

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

findstr /i/d:\winnt; \winnt\systerm32 aa*b *.ini.

В вышеупомянутой командной строке, «findstr» является параметром 0, «/i» - параметром 1, «/d:\wirnnt;\wirmt\system32» является параметром 2, «aa*b» - параметром 3, и «*.ini» - параметром 4. «Опция» является параметром к cmdlet, который обычно используется для определения изменения к заданному по умолчанию поведению программы. Продолжая с командной строкой из вышеуказанного примера, «/i» и «/d» являются вариантами. «Параметр опции» - входной параметр, который следует за некоторыми вариантами. В некоторых случаях, параметр опции включен в ту же самую строку параметра как опция. В других случаях, опция-параметр включена как следующий параметр. Обратимся вновь к вышеупомянутой командной строке, где «winnt; \winnt\system32» является опцией-параметром. «Операнд» является параметром к cmdlet, который в общем случае используется как объект, поставляющий программе информацию, необходимую для завершения обработки программы. Операнды обычно следуют за вариантами в командной строке. Обратимся к командной строке из примера выше, где «aa*b» и «*.im» - операнды. «Подходящий для синтаксического анализа поток» включает параметры.

Обратимся к фиг.13, где синтаксический анализатор 220 анализирует подходящий для синтаксического анализа поток (например, командную строку 1350) в последовательные части 1320-1326 (например, часть 1322 «where»). Каждая часть 1320-1326 связана с одним из cmdlets 1330-1336. Синтаксический анализатор 220 и механизм 224 выполняют различную обработку, такую как синтаксический анализ, проверка правильности параметра, генерацию данных, обработку параметра, кодирование параметра и документацию параметра. Поскольку синтаксический анализатор 220 и механизм 224 выполняют общие функциональности над входными параметрами командной строки, оболочка 200 административной сервисной программы способна выдать непротиворечивые сообщения об ошибках пользователю.

Можно заметить, что исполняемые cmdlets 1330-1336, написанные в соответствии с представленной оболочкой административной сервисной программы, требуют меньшего количества кода, чем команды в предшествующих административных средах. Каждый исполняемый cmdlet 1330-1336 идентифицирован, используя его соответствующую последовательную часть 1320-1326. Кроме того, каждый исполняемый cmdlet 1330-1336 выводит объекты (представленные стрелками 1340, 1342, 1344, и 1346), которые являются вводом, в качестве входных объектов, (представленных стрелками 1341, 1343, и 1345) к следующей конвейерной cmdlet. Эти объекты могут быть введены через передачу ссылки (например, дескриптора) объекту. Исполняемые cmdlets 1330-1336 могут тогда выполнять дополнительную обработку на объектах, которые были переданы в них.

Фиг.14 является логической блок-схемой, иллюстрирующей более подробно обработку командных строк, подходящих для использования в процессе для обработки ввода, показанного на фиг.9. Обработка командной строки начинается в блоке 1401, где или синтаксический анализатор, или механизм сценария идентифицируют командную строку во вводе. Вообще базовый механизм выполняет установку и упорядочивание потока данных cmdlets. Установка и упорядочивание для одного cmdlet описываются ниже, но они применимы к каждому cmdlet в конвейере. Обработка переходит к блоку 1404.

В блоке 1404 идентифицируется cmdlet. Идентификация cmdlet может быть произведена через регистрацию. Базовый механизм определяет, является ли cmdlet локальным или удаленным. Cmdlet может выполняться в следующих местах: 1) в прикладной области оболочки административной сервисной программы; 2) в другой прикладной области того же самого процесса, что и оболочка административной сервисной программы; 3) в другом процессе на том же самом компьютерном устройстве; или 4) на удаленном компьютерном устройстве. Взаимодействие между cmdlets, оперирующими в тех же самых процессах, происходит через объекты. Связь между cmdlets, работающих в различных процессах, происходит через преобразованный в последовательную форму структурный формат данных. Один примерный, преобразованный в последовательную форму структурный формат данных, основан на расширяемом языке разметки (XML). Обработка переходит к блоку 1406.

В блоке 1406 создается экземпляр объекта crndlet. Примерный процесс для создания экземпляра cmdlet описывается ниже при описании фиг.15. Когда объект cmdlet создан, обработка переходит к блоку 1408.

В блоке 1408 заполняются свойства, связанные с объектом cmdlet. Как описано выше, разработчик объявляет свойства в классе cmdlet или во внешнем источнике. Короче говоря, оболочка административной сервисной программы декодирует объект(ы), входящие в cmdlet, созданному от класса cmdlet, основываясь на названии и типе, который объявлен для свойства. Если типы различны, тип может быть приведен через менеджер расширенных типов данных. Как упоминалось ранее, в конвейерных командных строках вывод каждого cmdlet может быть списком дескрипторов объектов. Следующий cmdlet может вводить этот список дескрипторов объектов, выполнять обработку, и передавать другой список дескрипторов объектов следующему cmdlet. Кроме того, как проиллюстрировано на фиг.7, входные параметры могут быть определены как приходящие из командной строки. Один примерный способ для заполнения свойств, связанных с cmdlet, описывается ниже при описании фиг.16. Как только cmdlet заполняется, обработка переходит к блоку 1410.

В блоке 1410 выполняется cmdlet. Короче говоря, обработка, предоставленная cmdlet, выполняется, по меньшей мере, однажды, и включает обработку для каждого входного к cmdlet объекта. Таким образом, если cmdlet является первым cmdlet в пределах конвейерной командной строки, обработка выполняется однажды. Для последующего cmdlets обработка выполняется для каждого объекта, который передается cmdlet. Один примерный способ для выполнения cmdlets описывается ниже при описании фиг.5. Когда входные параметры приходят только из командной строки, выполнение cmdlet использует заданные по умолчанию методы, предоставленные базовым вариантом cmdlet. Как только cmdlet заканчивает выполнение, обработка переходит к блоку 1412.

В блоке 1412 очищается cmdlet. Это включает вызов деструктора для связанного объекта cmdlet, который является ответственным за освобождение памяти и т.п. Обработка командной строки после этого закончена.

Примерный процесс для создания объекта cmdlet

Фиг.15 является логической блок-схемой, иллюстрирующей примерный процесс для создания объекта cmdlet, подходящего для использования в обработке командных строк, показанных на фиг.14. К этому моменту структура данных cmdlet была разработана, и атрибуты и ожидаемые входные параметры были определены. Cmdlet был откомпилирован и был зарегистрирован. Во время регистрации имя класса (то есть имя cmdlet) записано в регистрационном хранилище, и метаданные, связанные с cmdlet, были сохранены. Процесс 1500 начинается в блоке 1501, где синтаксический анализатор получает ввод (например, нажатия клавиш), индицирующий cmdlet. Синтаксический анализатор может распознать ввод как cmdlet, ища ввод внутри системного реестра и связывая ввод с одним из зарегистрированных cmdlets. Обработка переходит к блоку 1504.

В блоке 1504 читаются метаданные, связанные с классом объекта cmdlet. Метаданные включают любую из директив, связанную с cmdlet. Директивы могут обратиться к cmdlet непосредственно или к одному или более параметрам. Во время регистрации cmdlet код регистрации регистрирует метаданные в постоянном хранилище. Метаданные могут быть сохранены в XML файле в преобразованном в последовательную форму формате, внешней базе данных, и т.п. Подобно обработки директив во время обработки сценария, каждая категория директив обрабатывается на разных стадиях. Каждая директива метаданных проводит свою собственную обработку ошибок. Обработка переходит к блоку 1506.

В блоке 1506, создается экземпляр объекта cmdlet, основываясь на идентифицированном классе cmdlet. Обработка переходит к блоку 1508.

В блоке 1508 получается информация о cmdlet. Это может произойти через отражение или другие средства. Информация дается об ожидаемых входных параметрах. Как упоминалось выше, параметры, которые объявлены общими (например, public string Name 730), соответствуют ожидаемым входным параметрам, которые могут быть определены в строке команды в командной строке или предоставлены через входной поток. Оболочка административной сервисной программы через менеджера расширенного типа, описанного на фиг.18, предоставляет общий интерфейс для возврата информации (на основе необходимости) вызывающему. Обработка переходит к блоку 1510.

В блоке 1510 применяются директивы применимости (например, Таблица 1). Директивы применимости обеспечивают то, чтобы класс использовался в конкретных машинных ролях и/или пользовательских ролях. Например, некий cmdlets может использоваться только администраторами домена. Если ограничение, указанное в одной из директив применимости, не выполнено, происходит ошибка. Обработка переходит к блоку 1512.

В блоке 1512 используются метаданные для обеспечения технологии intellisense. К этому моменту в обработке полная строка команды еще не была введена. Оболочка административной сервисной программы, однако, знает доступные cmdlets. Как только cmdlet будет определен, оболочка административной сервисной программы узнает входные параметры, которым позволяется отразиться над объектом cmdlet. Таким образом, оболочка административной сервисной программы может автоматически завершить cmdlet, как только будет предоставлена часть, устраняющая неоднозначности названия cmdlet, и затем автоматически завершить входной параметр, как только часть входного параметра, устраняющая неоднозначности, будет напечатана на командной строке. Автоматическое завершение может произойти, как только часть входного параметра сможет идентифицировать один из входных параметров однозначно. Кроме того, автоматическое завершение сможет также произойти на именах cmdlet и операндах. Обработка переходит к блоку 1514.

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

Примерный процесс для заполнения cmdlet

Примерный процесс для заполнения cmdlet проиллюстрирован на фиг.16 и описывается теперь вместе фиг.5. В одной примерной оболочке административной сервисной программы базовый механизм выполняет обработку для заполнения параметров для cmdlet. Обработка начинается в блоке 1601 после того, как образец cmdlet был создан. Обработка переходит к блоку 1602.

В блоке 1602 находится параметр (например, ProcessName), объявленный в cmdlet. Основываясь на объявлении cmdlet, базовый механизм распознает, что приходящие входные объекты предоставляют свойство по имени «ProcessName». Если тип входящего свойства отличается от типа, указанного в объявлении параметров, тип будет приведен через менеджер расширенного типа. Процесс приведения типов данных объясняется ниже в подразделе, называемом «Пример обработки менеджера расширенного типа». Обработка переходит к блоку 1603.

В блоке 1603 получают атрибут, связанный с параметром. Атрибут идентифицирует, является ли входной источник для параметра командной строкой или приходит ли он от конвейера. Обработка переходит к решающему блоку 1604.

В решающем блоке 1604 определяется, определяет ли атрибут входной источник как командную строку. Если входной источник является командной строкой, обработка переходит к блоку 1609. Иначе обработка переходит к решающему блоку 1605.

В решающем блоке 1605 определяется, должно ли использоваться имя свойства, указанного в объявлении, или должно использоваться отображение для имени свойства. Это определение основывается на том, определил ли ввод команды отображение для параметра. Следующая строка иллюстрирует примерное отображение параметра «ProcessName» в член «foo» входящего объекта:

$get?process|where han* -gt500|stop/process-ProcessName<-foo

Обработка переходит к блоку 1606.

В блоке 1606 применяется отображение. Отображение меняет название ожидаемого параметра из «ProcessName"» в «foo», который после этого используется базовым механизмом для анализа входящие объектов и идентификации правильного ожидаемого параметра. Обработка переходит к блоку 1608.

В блоке 1608 менеджер расширенного типа делается запрос для определения местонахождение значения для параметра в пределах входящего объекта. Как объясняется при описании {продленным} менеджера расширенного типа, менеджер расширенного типа берет название параметра и использует отражение для идентификации параметра во входящем объекте с именем параметра. Менеджер расширенного типа может также выполнить, в случае необходимости, другую обработку для параметра. Например, менеджер расширенного типа может привести тип данных к ожидаемому типу данных через механизм преобразования, описанный выше. Обработка переходит к решающему блоку 1610.

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

В решающем блоке 1610 определяется, есть ли другой ожидаемый параметр. Если есть другой ожидаемый параметр, обработка возвращается назад к блоку 1602 и продолжает, как описано выше. Иначе обработка закончена и происходит возврат.

Таким образом, как показано, cmdlets действует как шаблон для измельчения входящих данных для получения ожидаемых параметров. Кроме того, ожидаемые параметры получаются без знания типа входящего объекта, предоставляющего значение для ожидаемого параметра. Это весьма отличается от традиционных административных сред. Традиционные административные среды точно взаимосвязаны и требуют, чтобы тип объекта был известен во времени компиляции. Кроме того, в традиционных средах ожидаемый параметр передали бы в функцию по значению или по ссылке. Таким образом, представленный механизм синтаксического анализа (например, «shredding») позволяет программистам определять тип параметра, не требуя от них определенно знать, как значения для этих параметров получаются.

Например, дадим следующее объявление для cmdlet Foo:

синтаксис командной строки может быть любым следующим:

$Foo-Name:(sting)-Recurse: True

$Foo-Name<sting>-Recurse True

$Foo-Name:(sting).

Набор правил может изменятся системными администраторами для того, чтобы приводить к желаемому синтаксису. Кроме того, синтаксический анализатор может поддерживать множественные наборы правил, так чтобы более чем один синтаксис мог использоваться пользователями. В сущности, грамматика, связанная со структурой cmdlet (например, Name или Bool Recurse) управляют синтаксическим анализатором.

Вообще, директивы синтаксического анализа описывают, как параметры, введенные как командная строка, должны отображаться к ожидаемым параметрам, идентифицированным в объекте cmdlet. Типы входных параметров проверяются для определения правильности. Если типы входных параметров не правильны, входные параметры могут быть приведены к тому, чтобы стать правильными. Если типы входных параметров не правильны и не могут быть приведены, напечатается ошибка использования. Ошибка использования позволяет пользователю узнать правильный ожидаемый синтаксис. Ошибка использования может получить информацию, описывающую синтаксис из директив документирования. Как только типы входных параметров были или отображены или были проверены, соответствующие члены в экземпляре объекта cmdlet заполняются. Поскольку члены заполнены, менеджер расширенного типа обеспечивает обработку типов входных параметров. Коротко говоря, обработка может включать механизм свойства пути, ключевой механизм, механизм сравнения, механизм преобразования, механизм универсализации, механизм отношений, и механизм набора свойств. Каждый из этих механизмов описан подробно ниже в разделе, называемом «Обработчик менеджера расширенного типа», который также включает иллюстративные примеры.

Примерный процесс для выполнения Cmdlet

Примерный процесс для выполнения cmdlet проиллюстрирован на фиг.17 и описывается теперь. В одной примерной среде административной сервисной программы базовый механизм выполняет cmdlet. Как упоминалось выше, код 1442 во втором методе 1440 выполняется для каждого входного объекта. Обработка начинается в блоке 1701, где cmdlet был уже заполнен. Обработка продолжается в блоке 1702.

В блоке 1702 находится инструкция для выполнения из кода 542. Обработка продолжается в решающем блоке 1704.

В решающем блоке 1704 определяется, включен ли перехватчик в инструкцию. Обратимся к фиг.5, где перехватчик может включить запрос API, предоставленный базовым механизмом. Например, инструкция 550 кода 542 из cmdlet 500 на фиг.5 вызывает confirmprocessing API, определяющий необходимые параметры, первую строку (например, «PID=»), и параметр (например, PID). Возвратимся к фиг.17, и если инструкция включает перехватчик, обработка переходит к блоку 1712. Таким образом, если команда, вызывающая confirmprocessing API определена, cmdlet работает в альтернативном режиме выполнения, который предоставляется средой. Иначе обработка переходит к блоку 1706, и выполнение продолжается в «нормальном» режиме.

В блоке 1706 обрабатывается инструкция. Обработка тогда переходит к решающему блоку 1708. В блоке 1708 определяется, включает ли код другую инструкцию. Если есть другая инструкция, обработка возвращается назад к блоку 1702 для получения следующей инструкции и обработки, как описано выше. Иначе обработка переходит к решающему блоку 1714.

В решающем блоке 1714 определяется, есть ли другой входной объект для обработки. Если есть другой входной объект, обработка переходит к блоку 1716, где cmdlet заполняется данными из следующего объекта. Процесс заполнения, описанный на фиг.16, выполняется со следующим объектом. Обработка тогда возвращается назад к блоку 1702 и обрабатывается, как описано выше. Как только все объекты будут обработаны, процесс выполнения cmdlet заканчивается и происходит возврат.

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

Дополнительная обработка, выполняемая в блоке 1712, теперь описывается вместе с примерной структурой 600 данных, проиллюстрированной на фиг.6. Как было объяснено выше, в базовом классе 600 команды могут быть параметры, объявление которых соответствуют дополнительным ожидаемым входным параметрам (например, переключатель).

Переключатель содержит предопределенную строку, и когда распознается, направляет базовый механизм для предоставления дополнительных функциональных возможностей cmdlet. Если параметр verbose 610 определен в командном входе, инструкции 614 verbose, выполняются. Следующее является примером командной строки, которая содержит переключатель verbose:

$get/process|where “han*”-gt500”|stop/process-verbose

Вообще, когда «-verbose» определен во вводе команды, базовый механизм выполняет команду для каждого входного объекта и передает актуальную команду, которая была выполнена для каждого входного объекта, хост-программе для отображения. Следующее является примером сгенерированного вывода, когда вышеупомянутая командная строка выполнена в примерной среде административной сервисной программы:

$stop/process PID=15

$stop/process PID=33

Если параметр 620 whatif определен в командном вводе, выполняются инструкции 624 whatif. Следующее является примером командной строки, которая содержит переключатель whatif:

$get/process|where “han*”-gt500”|stop/process-whatif.

Вообще, когда «-whatif» определен, базовый механизм фактически не выполняет код 542, а скорее посылает команды, которые были бы выполнены, хост-программе для отображения. Следующее является примером сгенерированного вывода, когда вышеупомянутая командная строка выполнена в среде административной сервисной программы данного изобретения:

#$stop/process PID=15

#$stop/process PID=33

Если параметр 630 подтверждения определен в командном вводе, подтверждается, что инструкции 634 выполняются. Следующее является примером командной строки, которая содержит переключатель confirm:

$get/process|where “han*”-gt500”|stop/process-confirm

Вообще, когда «-confirm» определен, базовый механизм запрашивает дополнительный пользовательский ввод о том, продолжать ли команду или нет. Следующее является примером сгенерированного вывода, когда вышеупомянутая командная строка выполнена в среде административной сервисной программы данного изобретения.

$stop/process PID 15

Y/N Y

$stop/process PID 33

Y/N N.

Как описано выше, примерная структура 600 данных может также включать метод 640 защиты, который определяет, можно ли разрешить задачу, которую требуют для выполнения. В традиционных административных средах каждая команда отвечала за проверку того, имеет ли человек, выполняющий команду, достаточные привилегии для выполнения команды. Чтобы выполнить эту проверку, необходим обширный код для обращения к информации из нескольких источников. Из-за этих сложностей, многие команды не выполняли проверку защиты. Изобретатели данной среды административной сервисной программы признают, что когда задача определена во вводе команды, необходимая информация для выполнения проверки защиты доступна в среды административной сервисной программы. Поэтому оболочка административной сервисной программы выполняет проверку защиты, не требуя сложного кода от разработчиков инструмента. Проверка защиты может быть выполнена для любого cmdlet, который определяет перехватчик в своем cmdlet. Альтернативно перехватчик может быть дополнительным входным параметром, который может быть определен в командном вводе, подобно сходному параметру, описанному выше.

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

Изобретатели данного изобретения распознают, что cmdlet требует запроса на действие, которое должно было быть выполнено. Кроме того, изобретатели оценили, что владелец процесса, в котором оболочка административной сервисной программы выполняется, передается источнику. Далее, изобретатели оценили, что ресурс определен в cmdlet. Поэтому, поскольку оболочка административной сервисной программы имеет доступ к этим элементам, изобретатели распознавали, что проверка защиты могла быть выполнена внутри оболочки административной сервисной программы, не требуя от разработчиков инструмента осуществлять проверку защиты.

Операция проверки защиты может быть выполнена любым числом дополнительных функциональных возможностей, требуемых в cmdlet, используя ловушку, такую, как confirmprocessing API. Альтернативно, проверка защиты может быть выполнена проверкой, был ли переключатель защиты введен в командную строку, подобно verbose, whatif и confirm. Для любой реализации метод checkSecurity вызывает API, предоставляемый процессом защиты (не показанным здесь), который предоставляет набор API для определения разрешений. Процесс защиты берет информацию, предоставленную оболочкой административной сервисной программы, и предоставляет результат, указывающий, может ли задача быть закончена. Оболочка административной сервисной программы может после этого выдать ошибку или только остановить выполнение задачи.

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

Примерная обработка менеджера расширенного типа

Как кратко упоминалось выше вместе с фиг.18, менеджер расширенного типа может выполнить дополнительную обработку на поставляемых объектах. Дополнительная обработка может быть выполнена по требованию синтаксического анализатора 220, механизм 222 сценария, или конвейерного процессора 402. Дополнительная обработка включает механизм свойства пути, ключевой механизм, механизм сравнения, механизм преобразования, механизм универсализации, механизм отношений и механизм набора свойств. Специалисты в данной области техники оценят, что менеджер расширенного типа может также быть расширен другой обработкой, не отступая от объема данного изобретения. Теперь описывается каждый из дополнительных механизмов обработки.

Сначала механизм свойства пути позволяет строке управлять свойствами объектов. В существующих системах отражения запросы могут сделать запрос свойств объекта. Однако в данном менеджере расширенного типа строка может быть определена так, чтобы обеспечивать навигационный путь к следующим свойствам объектов. Следующее является иллюстративным синтаксисом для свойства пути: P1.P2.P3.P4.

Каждый компонент (например, P1, P2, P3, и P4) включают строку, которая может представлять свойство, метод с параметрами, метод без параметров, поле, XPATH (язык для адресации частей XML), или им подобное. XPATH определяет строку запроса для поиска элемента (например, «/FOO = 13»). В строке может быть включен специальный символ для того, чтобы определенно указать тип компонента. Если строка не содержит специальный символ, менеджер расширенного типа может произвести поиск для определения типа компонента. Например, если компонент P1 является объектом, менеджер расширенного типа может сделать запрос, является ли P2 свойством объекта, метод объекта, полем объекта или набором свойств. Как только менеджер расширенного типа идентифицирует тип для P2, будет выполнена обработка, согласно этому типу. Если компонент не является не одним из вышеупомянутых типов, менеджер расширенного типа может дополнительно сделать запрос расширенных источников для того, чтобы определить, существует ли функция преобразования для преобразования типа P1 в тип P2. Эти и другие поиски теперь будут описаны, используя иллюстративные командные строки и показывая соответствующий вывод.

Нижеследующее является иллюстративной строкой, которая включает свойства пути:

$get/process|/where hand* -gt>500|format/table name.toupper, ws.kb, exe*.ver*.description.tolower.trunc(30).

В вышеупомянутой иллюстративной строке есть три пути свойства: (1) «name.toupper»; (2) «ws.kb»; и (3) «exe*.ver*.description.tolower.tranc(30). Перед описанием этих свойств путей нужно обратить внимание, что «name», «ws», и «exe» определяют свойства для таблицы. Кроме того, нужно обратить внимание, что каждое из этих свойств является непосредственным свойством входящего объекта, первоначально сгенерированного «get/process» и затем проведенного через конвейер различных cmdlets. Теперь опишем обработку, связанную с каждым из трех свойств пути.

В первом свойстве пути (то есть «name.toupper»), name является непосредственным свойством входящего объекта и также само является объектом. Менеджер расширенного типа делает запрос к системе, используя приоритетный поиск, описанный выше, для того чтобы определить тип для toupper. Менеджер расширенного типа обнаруживает, что toupper не является свойством. Однако toupper может быть методом, наследующим строковый тип для преобразования символов строчных букв в символы верхнего регистра в строке. Альтернативно менеджер расширенного типа может сделать запрос расширенных метаданных для определения того, есть ли любой код третьей стороны, который может преобразовать объект name в верхний регистр. После нахождения типа компоненты, обработка выполняется в соответствии с типом этой компоненты. Во втором свойстве пути (то есть «ws.kb») «ws» является непосредственным свойством входящего объекта и также само является объектом. Менеджер расширенного типа определяет, что «ws» является целым числом. Тогда менеджер расширенного типа делает запрос, является ли kb свойством целого числа, является ли kb методом целого числа, и наконец делает запрос, знает ли какой-либо код, как взять целое число и преобразовать целое число к типу kb. Код третьей стороны регистрируется для выполнения этого преобразования, и преобразование выполняется.

В третьем свойстве пути (то есть «exe*.ver*.description.tolower.trunc(30)») есть несколько компонент. Первая компонента («exe*») является непосредственным свойством входящего объекта и также само является объектом. Вновь менеджер расширенного типа направляет вниз запрос на поиск для того, чтобы обработать второй компонент («ver*»). Объект «exe*» не имеет свойства или метода «ver*», так что менеджер расширенного типа делает запрос расширенных метаданных для определения того, есть ли какой-нибудь код, который зарегистрирован для преобразования имени исполняемого файла в версию. Для данного примера, такой код существует. Код может взять строку имени исполняемого файла и использовать его для открытия файла, затем обратится к объекту версионного блока, и возвратить свойство описания (третий компонент («описание») объекта версионного блока. Менеджер расширенного типа после этого выполняет этот же самый механизм поиска для четвертого компонента («tolower») и пятого компонента («trunc(40)»). Таким образом, как проиллюстрировано, менеджер расширенного типа может выполнить весьма сложную обработку командной строки необходимости администратору написать какой-нибудь определенный код. Таблица 1 иллюстрирует вывод, сгенерированный для иллюстративной строки.

Таблица 1

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

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

Таблица 2

Cmdlet compare/time написан для того, чтобы сравнивать два объекта datetime. В этом случае объект DateTime поддерживает интерфейс IComparable.

Другой механизм 1824 запроса включают механизм преобразования. Менеджер расширенного типа позволяет коду быть зарегистрированным, заявляя его возможность выполнить определенные преобразования. Тогда, когда объект типа А является вводом, и cmdlet определяет объект типа B, менеджер расширенного типа может выполнить преобразование, используя одно из зарегистрированных преобразований. Менеджер расширенного типа может выполнить ряд преобразований для того, чтобы привести тип А к типу B. Свойство пути, описанное выше («ws.kb»), иллюстрирует механизм преобразования.

Другой механизм 1824 запроса включает механизм универсализации. Универсализация ссылается на подстановочный символ (символ, заменяющий любой символ) в строке. Механизм универсализации вводит строку с подстановочный символом и производит установку объектов. Менеджер расширенного типа позволяет коду зарегистрироваться для того, чтобы определить обработку подстановочного знака. Свойство пути, описанное выше («exe*.ver*.description.tolower.trunc(30)) иллюстрирует механизм универсализации. Зарегистрированный процесс может предоставить универсализацию для имен файла, файловых объектов, входящих свойств, и т.п.

Другой механизм 1824 запроса включает механизм набора свойства. Механизм набора свойства позволяет имени быть определенным для набора свойств. Администратор может тогда определить имя в командной строке для получения набора свойств. Набор свойств может быть определен различными способами. Одним способом, предопределенный параметр, такой как «?», может быть введен как входной параметр для cmdlet. Операционная среда после распознания предопределенного параметра перечисляет все свойства входящего объекта. Список может быть в графическом интерфейсе пользователя, который позволяет администратору легко отметить (например, «щелчком») желательные свойства и дать имя набору параметров. Информация о наборе параметров после этого сохраняется в расширенных метаданных. Иллюстративная строка, вызывающая механизм набора параметров, показан ниже, наряду с соответствующим выводом, в Таблице 3:

$get/process|where “han*”-gt>500”|format/table config.

В этой иллюстративной строке был определен набор параметров, называемый "cotifig", для включения свойства name, свойства process id (PID), и свойство priority. Вывод для таблицы показан ниже.

Таблица 3.

Другой механизм 1824 запроса включает механизм отношений. В отличие от систем традиционного типа, которые поддерживают одно отношение (то есть наследование), механизм отношений поддерживает выражения больше чем одного отношения между типами. Как и раньше, эти отношения зарегистрированы. Отношения могут включать найденные элементы, которые объект использует, или нахождение элементов, которые используют объект. Менеджер расширенного типа может обратиться к онтологиям, которые описывают различные отношения. Используя расширенные метаданных и код, может быть описана спецификация обращения к любой службе онтологии, например OWL, DAWL, и т.п. Следующее является часть иллюстративной строки, которая использует механизм отношений:.OWL: «строка».

Идентификатор «OWL» идентифицирует службу онтологии, и «строка» определяет определенную строку в службе онтологии. Таким образом, менеджер расширенного типа может обратится к типам, предоставляемым службами онтологии.

Примерный процесс для отображения данных командной строки

Представленный механизм предоставляет данные, управляющие выводом командной строки. Форматирование и вывод данных предоставляется одним или более cmdlets в конвейере cmdlets. Как правило, эти cmdlets включены в неуправляющие cmdlets, описанные выше при описании фиг.2. Cmdlets может включить форматирующий cmdlet, размечающий cmdlet, преобразующий cmdlet, трансформирующий cmdlet, и выводящий cmdlet.

Фиг.19 графически изображает примерные последовательности 1901-1907 из этих cmdlets в конвейера. Первая последовательность 1901 иллюстрирует выводящий cmdlet 1910 как последний cmdlet в конвейере. Тем же самым способом, что и описанный выше для другого cmdlets, выводящий cmdlet 1910 принимает поток конвейерных объектов, сгенерированных и обработанных другим cmdlets в конвейере. Однако в отличие от большинства cmdlets, выводящий cmdlet 1910 не выдает конвейерные объекты для другого cmdlets. Вместо этого выводящий cmdlet 1910 ответственен за визуализацию/отображение результатов, сгенерированные конвейером. Каждый выводящий cmdlet 1910 связан с назначением вывода, таким, как устройство, программа, и т.п. Например, для консольного устройства, выводящий cmdlet 1910 может быть определен как out/console; для браузера интернета, выводящий cmdlet 1910 может быть определен как out/browser; и для окна, выводящий cmdlet 1910 может быть определен как out/window. Каждый определенный выводящий cmdlet знаком с возможностями связанного с ним устройства назначения. Региональная информация (например, форматы данных и валюты) обрабатывается выводящим cmdlet 1910, если только cmdlet преобразования не предшествовал в конвейере выводящему cmdlet. В этой ситуации, cmdlet преобразования обрабатывает региональную информацию.

Каждый хост отвечает за поддержку некоторых выводящих cmdlets, таких как out/console. Хост также поддерживает любые cmdlet спецификации назначения хоста (например, out/chart, который направляет вывод к диаграмме, предоставленной приложением электронной таблицы). В добавлении, хост отвечает за предоставление заданной по умолчанию обработки результатов. Выводящий cmdlet в этой последовательности может решить реализацию своего поведения вызовом другого обрабатывающего вывод cmdlets (типа format/markup/conver/transform). Таким образом, выводящий cmdlet может неявно модифицировать последовательность 1901 к любой из других последовательностей? или может добавить свои собственные дополнительные format/output cmdlets.

Вторая последовательность 1902 иллюстрирует форматирующий cmdlet 1920 перед выводящим cmdlet 1910. Для этой последовательности форматирующий cmdlet 1920 принимает поток конвейерных объектов, сгенерированных и обработанных другим cmdlets в конвейере. Короче говоря, форматирующий cmdlet 1920 предоставляет способ выбрать свойства отображения и способ определить свойства страницы, такие как форма, размеры столбцов, заголовков, нижних колонтитулов и т.п. Форма может включить таблицу, широкий список, колоночный список и т.п. Кроме того, форматирующий cmdlet 1920 может включать вычисления общего количеств или сумм. Примерная обработка, выполняемая форматирующим cmdlet 1920, описывается ниже при описании фиг.20. Кратко, форматирующий cmdlet выдает форматирующие объекты, в дополнение к выдаче конвейерных объектов. Форматирующие объекты могут быть распознаны внизу выводящим cmdlet (например, выводящим cmdlet 1920 в последовательности 1902) через менеджер расширенного типа или другой механизм. Выводящий cmdlet 1920 может выбрать, использовать ли выдаваемые форматирующие объекты или игнорировать их. Выводящий cmdlet определяет свойства страницы, основываясь на данных свойства страницы, указанных в информации отображения. В некоторых образцах, модификации к свойствам страницы могут быть определены выводящим cmdlet. В одном примерном процессе выводящий cmdlet может определять неспецифицированную ширину столбца, находя максимальную длину для каждого свойства предопределенного числа объектов (например, 50) и устанавливая ширину столбца к максимальной длине. Форматирующие объекты включают информацию о форматирование, информацию о верхнем/нижнем колонтитулах, и т.п.

Третья последовательность 1903 иллюстрирует форматирующий cmdlet 1920 перед выводящим cmdlet 1910. Однако в третьей последовательности 1903 размечающий cmdlet 1930 является конвейером между форматирующим cmdlet 1920 и выводящим cmdlet 1910. Размечающий cmdlet 1930 предоставляет механизм для добавления аннотации параметра (например, шрифт, цвет) к выбранным параметрам. Таким образом, размечающий cmdlet 1930 появляется перед выводом cmdlet 1910. Аннотации параметра могут быть реализованы, используя «множество теневых параметров», или добавляя аннотации параметров в специальное пространство имен в множестве параметров. Размечающий cmdlet 1930 может появиться перед форматирующим cmdlet 1920 до тех пор, пока аннотации разметки могут быть поддержаны во время обработки форматирующего cmdlet 1920.

Четвертая последовательность 1904 вновь иллюстрирует форматирующий cmdlet 1910 перед выводящим cmdlet 1910. Однако в четвертой последовательности 1904, cmdlet 1940 преобразования является конвейером между форматирующим cmdlet 1920 и выводящим cmdlet 1910. Cmdlet 1940 преобразования также конфигурируется для обработки форматирующего объекта, выданного форматирующим cmdlet 1920. Cmdlet 1940 преобразования преобразует конвейерные объекты в специально кодированные, основываясь на форматирующих объектах. Cmdlet 1940 преобразования связан с определенным кодированием. Например, cmdlet 1940 преобразования, который преобразует конвейерные объекты в объекты Active Directory (ADO), может быть объявлен как «convert/ADO» в командной строке. Аналогично, cmdlet 1940 преобразования, который преобразует конвейерные объекты в разделенные запятыми значения (csv), могут быть объявлены как «convert/csv» в командной строке. Часть cmdlets 1940 преобразования (например, convert/XML и convert/HTML) могут быть блокирующими командами, означающие, что все конвейерные объекты получены перед выполнением преобразования. Как правило, выводящий cmdlet 1920 может определить, использовать ли информацию форматирования, предоставленную форматирующими объектами. Однако когда cmdlet 1920 преобразования появляется перед выводящим cmdlet 1920, фактическое преобразование данных уже произошло до того, как выводящий cmdlet получил объекты. Поэтому, в данной ситуации, выводящий cmdlet не сможет игнорировать преобразование.

Пятая последовательность 1905 иллюстрирует форматирующий cmdlet 1930, размечающий cmdlet 1940, cmdlet 1940 преобразования, и выводящий cmdlet 1910 в этом порядке. Таким образом, это иллюстрирует, что размечающий cmdlet 1930 может появиться перед cmdlet 1940 преобразования.

Шестая последовательность 1906 иллюстрирует форматирующий cmdlet 1920, определенный cmdlet преобразования (например, convert/xml cmdlet 1940'), определенный cmdlet преобразования (например, transform/xslt cmdlet 1950), и выводящий cmdlet 1910. Convert/xml cmdlet 1940' преобразует конвейерные объекты в документ расширенный язык разметки (XML). Transform/xslt cmdlet 1950 преобразовывает XML документ в другой XML документ, используя таблицу стилей Extensible Style Language (XSL). Процесс преобразования обычно упоминается как расширяемое преобразование языка стиля (XSLT), в котором обработчик XSL читает XML документ и следует инструкциям в таблице стилей XSL для создания нового документ XML.

Седьмая последовательность 1907 иллюстрирует форматирующий cmdlet 1920, размечающий cmdlet 1930, определенный cmdlet преобразования (например, convert/xml cmdlet 1940'), определенный cmdlet трансформации (например, transform/xslt cmdlet 1950), и выводящий cmdlet 1910. Таким образом, седьмая последовательность 1907 иллюстрирует наличие размечающего cmdlet 1930, идущего в противоположную сторону от cmdlet преобразования к трансформирующему cmdlet.

Фиг.20 иллюстрирует примерную обработку 2000, выполняемую форматирующим cmdlet. Процесс форматирования начинается в блоке 2001 после того, как форматирующий cmdlet был проанализирован и вызван синтаксическим анализатором и конвейерным обработчиком способом, описанным выше. Обработка переходит к блоку 2002.

В блоке 2002 конвейерный объект получается, как ввод в форматирующий cmdlet. Обработка переходит к блоку 2004.

Блок 2004, где запрос инициируется для идентификации тип конвейерного объекта. Этот запрос выполняется менеджером расширенного типа, как описывалось выше при описании фиг.18. Как только менеджер расширенного типа идентифицировал тип для объекта, обработка переходит к блоку 2006.

В блоке 2006 идентифицированный тип ищется в информации отображения. Примерный формат для информации отображения проиллюстрирован на фиг.21 и будет описан ниже. Обработка переходит к решающему блоку 2008.

В решающем блоке 2008 определяется, определен ли идентифицированный тип в информации отображения. Если нет никакого входа в информации отображения для идентифицированного типа, обработка заканчивается. Иначе обработка переходит к блоку 2010.

В блоке 2010 форматирующая информация, связанная с идентифицированным типом, получена от информации отображения. Обработка переходит к блоку 2012.

В блоке 2012 информация выдается на конвейер. Как только информация выдана, обработка закончена.

Примерная информация, которая может быть выдана, теперь описывается с дополнительными деталями. Информация может включать информацию форматирования, информацию о верхнем/нижнем колонтитуле, и групповой сигнальный объект end/begin. Информация форматирования может включать форму, метку, нумерация/маркеры, размеры столбца, тип символьного кодирования, свойства содержимого шрифта, длину страницы, название группы по свойствам и т.п. Каждый из них может иметь дополнительные спецификации, связанные с ним. Например, форма может определять, является ли форма таблицей, списком или подобное им. Метки могут определять, использовать ли заголовки столбца, метки списка, или подобные им. Символьное кодирование может определять ASCII, UTF-8, Unicode, и т.п. Свойства содержимого шрифта могут определять шрифт, который применяется к значениям свойств, которые являются отображением. Может использоваться заданное по умолчанию значение свойства шрифта (например, Courier New, 10 point), если свойства содержимого шрифта не определены.

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

Групповые объекты сигнала начала/конца выдаются, когда форматирующий cmdlet определяет, что сгруппированные свойства изменились. Когда это происходит, форматирующий cmdlet обрабатывает поток конвейерных объектов, как предварительно отсортированных, и не делает их пересортировку. Групповые объекты сигнала начала/конца может быть вставлены в конвейерные объекты. Множественные сгруппированные свойства могут быть определены для вложенной сортировки. Форматирующий cmdlet может также выдать объект конца формата, который включает финальные суммы и итоги.

Обратимся кратко к фиг.21, примерная информация 2100 отображения находится в структурном формате и содержит информацию (например, форматирующую информацию, информацию верхнего/нижнего колонтитула, сгруппированные свойства или методы), связанную с любым объектом, который был определен. Например, информация 2100 отображения может быть основанной на XML. Каждое из вышеупомянутых свойств может быть тогда определено в информации отображения. Информация в информации 2100 отображения может быть заполнена владельцем объектного типа, который вводится. Операционная среда предоставляет некоторые API и cmdlets, которые позволяют владельцу обновлять информацию отображения, создавая, удаляя и изменяя входы.

Фиг.22 является табличным списком примерного синтаксиса 2201-2213 для некоторых форматирующих cmdlets (например, format/table, format/list, и format/wide), cmdlets разметки (например, add/markup), cmdlets преобразования (например, convert/text, convert/sv, convert/csv, convert/ADO, convert/XML, convert/html), cmdlets трансформации (например, transform/XSLT) и выводящий cmdlets (например, out/console, out/file). Фиг.23 иллюстрирует результаты, визуализированные out/console cmdlet, используя различные конвейерные последовательности, обрабатывающего вывод cmdlets (например, форматирующие cmdlets, cmdlets преобразования, и размечающие cmdlets).

Как было описано, механизм для обеспечения расширенных функциональных возможностей для команд командной строки может использоваться в среде административной сервисной программы. Однако специалисты в данной области техники могут оценить, что механизм может использоваться в различных средах, которые вводят команды командной строки. Например, функциональные возможности «whatif» можгут быть включены в автономные команды вставкой необходимых команд для анализа командной строки для параметра «whatif» и выполнения обработки режима моделирования. Существующий механизм для предоставления расширенных функциональных возможностей командам командной строки весьма отличается от традиционных механизмов для расширения функциональных возможностей. Например, в традиционных механизмах, каждая команда, которая запрашивает расширенные функциональные возможности, должна была включить код в команду. Сама команда тогда должна была бы анализировать командную строку для определения того, был ли предоставлен переключатель (например, verbose, whatif), и соответственно выполнить расширенные функциональные возможности. Напротив, представленный механизм позволяет пользователям определять параметр в командной строке для того, чтобы выполнить расширенные функциональные возможности для индивидуального cmdlet, пока cmdlet включает перехватчик к расширенным функциональным возможностям. Таким образом, представленный механизм минимизирует количество кода, который системные администраторы, должны написать. Кроме того, используя представленный механизм, расширенные функциональные возможности осуществляются одинаковым способом.

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

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

2. Способ по п.1, в котором указанный переключатель содержит «whatif».

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

4. Система по п.3, в которой указанный переключатель содержит «whatif».

5. Система по п.3, в которой указанный альтернативный режим выполнения визуально отображает моделируемые результаты выполнения команды.

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

7. Система по п.6, в которой указанный переключатель содержит «whatif».

8. Система по п.6, в которой указанный альтернативный режим выполнения визуально отображает моделируемые результаты выполнения команды.