NEW Microcom1 ::: СОФТ ->Новости командной строки

Софт

Железо

Рассылка

Support

NEW Microcom1

Софт --- самое свежее и новое

На главную

Новости командной строки

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

Слухами о 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

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

out-list

                            out-grid

не говоря уж о

out-html

                            out-excel

и тем более

export-xml

что позволяет применять MSH-сценарии в решениях практически любой сложности.

Еще одна концепция, которую просто нельзя не упомянуть, -- так называемые "провайдеры", обеспечивающие прозрачный доступ к любым древовидным структурам аналогично тому, как это делается для файловой системы. Скажем, провайдер реестра определяет два "накопителя" HKLM: и HKCU:, с которыми можно работать, как с обычными дисками -- перемещаться по разделам посредством cd, просматривать их содержимое с помощью

dir

(get-children), создавать и удалять ключи (именно поэтому MSH изначально оперирует не понятиями "файл" и "папка", а более общими и универсальными item и location) и т. д. В нынешнем выпуске уже имеется и провайдер Active Directory, так что сисадмины будут вооружены, что называется, до зубов.

Хотя столь краткий обзор вряд ли позволит получить полное представление о MSH, надеемся, читатели все же уловили суть главных концепций и оценили их красоту. Как уже говорилось, компонент только проходит "обкатку", и трудно даже предугадать, что может быть изменено или добавлено, -- а "жалоб и предложений" у бета-тестеров предостаточно. Надеемся лишь, что разработчики дадут нам повод продолжить данную тему.

Используются технологии uCoz