Новости командной строки
13 апрель, 2004 - 23:00Игорь Дериев
Слухами о Longhorn Internet полнится. Чем дальше переносится выход будущей ОС
(пока официально объявлено, что она не появится ранее 2006 г.), тем больше слухов,
ожиданий и информации -- как относительно достоверной (за два года все-таки многое
может измениться), так и из разряда "слышал звон, да не знаю, где он".
Планы Microsoft как всегда амбициозны, а намерения воплотить их в жизнь, похоже,
весьма серьезны. Собственно, этим не в последнюю очередь и объясняется столь длительный
процесс разработки: и WinFS -- некая SQL-подобная надстройка над файловой системой
(в качестве которой, видимо, все же останется NTFS), и Avalon -- совершенно новый
3D (во всяком случае, векторный, а не растровый) GUI, и многие другие компоненты
действительно требуют немалых усилий, тщательной проработки и всеобъемлющего тестирования.
|
Так выглядит вывод, формируемый
out-grid
|
Впрочем, большая часть обещаемых нововведений настолько хорошо укладывается в
традиционные рамки воззрений и предпочтений Microsoft, что говорить о каких-то
"революциях" если и не бессмысленно, то по крайней мере преждевременно.
Компания считается главным апологетом графических интерфейсов и общесистемной
объектной модели, и в этом смысле замена 2D на 3D, а COM/DCOM на .NET не выглядит
таким уж радикальным шагом. Но Longhorn, несомненно, таит в себе множество неожиданностей
и даже сюрпризов. Скажем, многие ли из нас могли предположить, что разработчики
займутся совершенствованием командной оболочки?
Тем не менее это так. Компонент под неброским названием Microsoft Command Shell (хотя сокращенно -- MSH, от Microsoft SHell) уже доступен для бета-тестеров и успешно работает под Windows XP. Единственное условие -- наличие необходимой версии .NET Framework, поскольку MSH не просто является полноценным .NET-приложением, но буквально пронизан .NET-идеологией. Достаточно сказать, что аналогом команд в MSH выступают так называемые "командлеты" (cmdlets), которые представляют собой не исполняемые файлы или встроенные функции хост-программы, а именно управляемые (managed) классы, хранящиеся в соответствующих сборках. К преимуществам данного подхода мы еще вернемся, а пока сделаем небольшое "лирическое отступление".
Действительно, нужна ли еще одна командная оболочка? Формально CMD.EXE недалеко ушел со времен старой доброй DOS, хотя и в этом интерпретаторе имеются отдельные весьма продвинутые возможности, а некоторые трюки позволяют решать довольно нетривиальные задачи. И все же ограничения ощутимы, не случайно существуют Kixtart, 4NT и масса других бесплатных и коммерческих альтернативных разработок. Многие пробелы способны закрыть WSH-сценарии, формально обеспечивающие доступ практически ко всем системным возможностям, в том числе и к WMI-интерфейсу. Однако их применение предполагает не только некоторые программистские навыки, но и четкую формулировку решаемой задачи. Выполнять же какие-то оперативные и "исследовательские" работы удобнее интерактивно -- из консоли. Поэтому GUI-инструменты и командная строка еще долго будут сосуществовать (в той или иной форме), а Microsoft даже обещает обеспечить полное соответствие их возможностей.
Между тем MSH (MSH.EXE) представляет собой именно обычную командную консоль, внешне идентичную CMD.EXE, -- все отличия скрыты от глаз и носят концептуальный характер. При более близком знакомстве, естественно, обнаруживается множество новинок и нюансов, упоминать которые нет особого смысла -- слишком многое еще может (и должно) измениться.
Учитывая, что "командлеты" -- далеко не произвольные структуры, система их именования выглядит вполне логичной:
<глагол>-<существительное> |
например:
get-location
write-console
set-alias |
Впрочем, последняя из приведенных команд предназначена для объявления псевдонимов, так что при необходимости можно организовать вполне привычную среду:
set-alias dir get-children
set-alias erase remove-item |
Многие псевдонимы, кстати, объявлены и используются изначально. Их также допускается назначать любым внешним исполняемым файлам либо сценариям. Все необходимые настройки могут быть включены в profile.msh, который автоматически обрабатывается при каждом запуске MSH.EXE.
Весьма существенно изменен и язык командных файлов. В нем имеются операторы ветвления (
if-elseif-else
), циклов (
while, for, foreach
), поддерживается объявление функций и переменных -- локальных, глобальных, массивов (в том числе и ассоциативных):
$local:a = 1,2,3,4,5
$a = @one => 1; string => "Hello!" |
а выделение блоков кода с помощью фигурных скобок, комментарии в любом месте строки (после символа #) и сокращенные арифметические операторы (+=, *=, ++ и т. п.) придают ему и вовсе профессиональный вид. Однако это не подразумевает отхода от концепций традиционных командных оболочек -- поддерживается и переадресация вывода, и конвейерная обработка, и прочие привычные инструменты и приемы. Более того, можно смело сказать, что именно здесь и сосредоточены основные новации.
В отличие от текстовых
stdin/stdout/stderr
, свойственных языку C, а следовательно, Unix и практически всем прежним оболочкам, потоки ввода/вывода MSH являются объектными -- в смысле .NET. Чтобы понять, какие возможности это открывает, достаточно уже самых простых примеров, вроде такого:
MSH C:>$d = get-children
MSH C:>$d.length
15 |
В каталоге оказалось 15 файлов -- на первый взгляд, несложный вывод, но чтобы сделать его с помощью прежних средств (
dir
и пр.), понадобится множество ухищрений. Допустимо и такое (как в командном файле, так и прямо в консоли):
MSH C:>$d = get-children
MSH C:>foreach ($f in $d) write-console $f.ToString()
atest.msh
breaktest.msh
...
|
.NET-объекты передаются и через привычный механизм каналов (pipe), это как минимум означает, что пользователям MSH впредь не придется колдовать с утилитами вроде
grep
,
find
и подобными для разбора текстового вывода. Второе преимущество данного подхода (и, конечно же, внутренней архитектуры .NET) -- свойство "самодокументирования". Действительно, кроме более или менее ожидаемых
get-help
и
get-command
, которые позволяют получить информацию о доступных "командлетах" и правилах их вызова, теперь присутствуют и более специальные средства:
MSH C:>get-children | get-member -property
MSH C:>get-children | get-member -methods |
В данном случае будут получены списки доступных свойств и методов для объектов, возвращаемых
get-children
(скажем, файлов). Одним словом, простор для творчества практически неограничен.
К тому же в MSH реализован ряд возможностей, в принципе, совершенно нехарактерных для командных оболочек. Например, поддержка GUI-конструкций. В самом простом случае это обычное окно сообщений
out-messagebox -title "Из MSH с любовью" -message "Продолжим?" -type
yesno |
в более сложном -- полноценная форма с кнопками, флажками, надписями, списками и прочими стандартными визуальными элементами управления Windows.
Сюда же относятся и богатейшие возможности вывода, в том числе и форматированного. Скажем, результат выполнения команды
get-service | sort-object status | format-table
-groupBy status servicename, canstop, canshutdown |
представляет собой таблицу, упорядоченную и сгруппированную по указанным признакам. А еще есть
не говоря уж о
и тем более
что позволяет применять MSH-сценарии в решениях практически любой сложности.
Еще одна концепция, которую просто нельзя не упомянуть, -- так называемые "провайдеры", обеспечивающие прозрачный доступ к любым древовидным структурам аналогично тому, как это делается для файловой системы. Скажем, провайдер реестра определяет два "накопителя" HKLM: и HKCU:, с которыми можно работать, как с обычными дисками -- перемещаться по разделам посредством
cd
, просматривать их содержимое с помощью
dir
(
get-children
), создавать и удалять ключи (именно поэтому MSH изначально оперирует не понятиями "файл" и "папка", а более общими и универсальными
item
и
location
) и т. д. В нынешнем выпуске уже имеется и провайдер Active Directory, так что сисадмины будут вооружены, что называется, до зубов.
Хотя столь краткий обзор вряд ли позволит получить полное представление о MSH, надеемся, читатели все же уловили суть главных концепций и оценили их красоту. Как уже говорилось, компонент только проходит "обкатку", и трудно даже предугадать, что может быть изменено или добавлено, -- а "жалоб и предложений" у бета-тестеров предостаточно. Надеемся лишь, что разработчики дадут нам повод продолжить данную тему.