Технология Windows Power­Shell по праву считается современной альтернативой работе с пакетными файлами (файлами команд оболочки Cmd.exe), но, похоже, многие пользователи по тем или иным причинам не торопятся расстаться со старыми привычками. Настоящая статья открывает серию публикаций, призванных помочь читателям избавиться от приверженности к технологиям пакетных файлов и перейти к использованию оболочки PowerShell.

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

История пакетных файлов

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

Когда появилась система MS-DOS, специалисты Microsoft включили аналогичное средство обработки пакетов в интерпретатор команд Command.com. Введите команды в текстовый файл, добавьте к его названию расширение. Bat, и интерпретатор выполнит все содержащиеся в файле команды.

С течением времени в последующих версиях DOS разработчики Microsoft оснащали пакетные файлы различными «наворотами». Так появились метки, оператор Goto, команды If для переходов и т. д. Здесь важно отметить, что пакетный «язык» не был разработан специально; он вырос из команды Submit системы CP/M.

Windows NT и Cmd.exe

Включаем ускоренную перемотку вперед. 1993 год, появляется операционная система Windows NT. Компания Microsoft предлагает потребителям консольное приложение Cmd.exe, которое по сей день направляет пользователю легендарное приглашение «C: prompt». Cmd.exe представляет собой дополненный вариант старого интерпретатора команд Command.com из системы MS-DOS, причем многие из используемых им команд — точные копии команд старого интерпретатора. Разумеется, это сделано специально, чтобы обеспечить обратную совместимость для пользователей, которые хотят продолжить работу со своими старыми пакетными файлами времен DOS. Cmd.exe даже обеспечивает выполнение «пакетного файла», если тот имеет расширение. Bat.

Из-за подобия программ Cmd.exe и Command.com, обратной совместимости с. Bat-файлами, а также изначального выбора специалистами Microsoft значка для приложения Cmd.exe (логотип MS-DOS) в течение многих лет пользователи пребывали в замешательстве. По сей день доски объявлений Windows пестрят сообщениями с вопросами о том, как сделать то или это «в системе DOS» (разумеется, фактически речь в этих вопросах идет о том, как решаются те или иные задачи в приложении Cmd.exe, которое на самом деле не имеет с системой DOS ничего общего).

Интерпретатор команд Cmd.exe функционально богаче, чем Command.com, и его пакетный «язык» соответствующим образом расширен. Среди расширений — итерация For/f, поддержка простых подпрограмм с помощью команды Call, а также средства локализации среды (Setlocal и Endlocal). Но хотя названные усовершенствования повышают полезность пакетного «языка», его по-прежнему отличает множество недочетов, вследствие чего попытка создать с его помощью нечто более сложное, чем простенький пакетный файл, может сопровождаться значительными трудностями.

Windows Script Host

Начиная с версии Windows 2000 (выпущенной в 1999 году) Microsoft расширила список средств для подготовки сценариев. Потребители получили сервер сценариев Windows Script Host (WSH), а также два настоящих встроенных языка программирования (VBScript и JScript — созданную разработчиками Microsoft версию JavaScript). Для обеспечения взаимодействия с операционной системой и приложениями в сценариях WSH используются объекты COM. И хотя сервер WSH исключительно полезен и отличается богатыми функциональными возможностями, последние ограничиваются установленными на компьютере объектами COM, и пользователь не получает доступа к интерфейсу командной строки.

Появление оболочки PowerShell

Взаимная совместимость пакетных файлов и сценариев WSH не предусмотрена. В сущности, мы имеем дело с отдельными инструментами, оснащенными различными интерфейсами (сценарии пакетных файлов и сценарии WSH не имеют друг с другом ничего общего). Понимая, что ситуация далека от идеальной, специалисты Microsoft в 2006 году выпустили оболочку Windows PowerShell. Эта технология, построенная на платформе. NET Framework, оснащена единым интерфейсом командной строки и интерфейсом для подготовки сценариев, обеспечивающим управление операционной системой Windows.

Так вот, теперь, когда в нашем распоряжении имеется среда Windows PowerShell, необходимость в работе со старомодными пакетными файлами (пакетными файлами оболочки Cmd.exe) отпадает. Жизнь идет вперед, и нам следует сосредоточиться на изучении PowerShell, особенно с учетом того, что Microsoft рассматривает эту оболочку в качестве главного средства автоматизации операционной системы Windows, а также корпоративных приложений.

Почему работу с пакетными файлами нужно прекратить

Существует пять веских причин, почему нам следует воздержаться от создания пакетных файлов (сценариев оболочки Cmd.exe) и вместо этого работать с новыми сценариями в PowerShell.

  1. За технологией PowerShell — будущее. Microsoft провозгласила PowerShell главным средством автоматизации операционной системы Windows, а также корпоративных приложений. Независимые производители поставляют библиотеки PowerShell для управления своими продуктами. Изучать PowerShell придется в любом случае, так почему бы не взяться за дело прямо сейчас?
  2. Пакетные файлы отличаются многочисленными странностями. Я частенько заглядываю на сайты, где публикуются ответы на вопросы, посвященные работе со сценариями, и должен сказать, что просто потерял счет вопросам о том, почему переменные среды не расширяются корректно и почему команда Start не функционирует должным образом. Поверьте, нет никакой нужды переживать по поводу ограничений пакетного языка Cmd.exe. Забудьте об этом и пользуйтесь языком сценариев, реализованным в оболочке PowerShell.
  3. PowerShell позволяет работать с пакетными файлами и инструментами командной строки. Переход на PowerShell не означает, что вам придется отказаться от пакетных файлов или средств командной строки. Старые пакетные файлы запускаются и с PowerShell, а инструменты командной строки по-прежнему функционируют безупречно.
  4. Язык сценариев PowerShell — это настоящий язык программирования. Чтобы им пользоваться, не нужно быть программистом, но, когда у вас возникнет необходимость реализовать в сценарии сложную логическую схему, вы убедитесь, что в PowerShell логика выражается проще, нежели в пакетном файле Cmd.exe. Во многих случаях одной командной строки PowerShell может быть достаточно для замены нескольких сотен строк кода пакетного файла.
  5. Технология PowerShell оперирует не текстовыми данными, а объектами, тогда как Cmd.exe и другие текстовые оболочки работают только с командами, выводимыми в тексте. Что же касается команд PowerShell, то они взаимодействуют с объектами. NET. Выполнять некоторые операции (такие, как синтаксический анализ даты и времени) с помощью пакетных сценариев Cmd.exe настолько неудобно, что это вызывает раздражение. А в оболочке PowerShell они выполняются на удивление просто.

Оставим «пакеты» в прошлом

Конечно, в ближайшее время технологии Cmd.exe не будут списаны в архив, однако у пользователей нет никаких оснований заниматься изучением особенностей старомодного пакетного языка. Забудьте о нем и сосредоточьте усилия на технологии PowerShell.

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