коммандлеты

[avva]

Про новый shell в Лонгхорне рассказывают вот тут (англ., ссылка от yms).

Хоть стой, хоть падай, честное слово. Двадцать лет ждали и просили Майкрософт, чтобы сделали нормальный shell с нормальными возможностями. Пережили поколения command.com'ов и cmd.exe, но так и не дождались.

И вот, нате вам, Майкрософт созрел. Объектно-ориентированная командная строка. “Коммандлеты”, возвращающие .NET-объекты. Гусары молчат.

Comments

[pure-white-snow.livejournal.com]

с графическими интерфейсом. Находящиеся где-нибудь в All Programms.

Но я сейчас подумал - лучше не стану подвергать сомнению надобность в shell. Ведь есть разные люди... Но я действительно не знаю, зачем он им нужен.
Мне CMD.EXE приходилось вызывать только для выполнения указанными выше командами всякой ерунды в случае проблем: проверить, что с сетью, останавливать и запускать сервиса, и всё такое. Что связано с плохим качеством работы имеющихся утилит (Microsoft Management Console, например).

[ltwood.livejournal.com]

Спасибо, что вспомнили ;)) Есть такие люди. Я вот пишу на C++ в far'е, компилируюсь из командной строки, пользуюсь кучей портированных из unix'а утилит и бывают дни, когда я вообще не запускаю ни одного приложения с графическим интерфейсом. И пишу я, кстати, тоже консольные приложения.

[pure-white-snow.livejournal.com]

а почему не в Visual Studio?
(Просто вопрос)

[dimrub.livejournal.com]

Например, потому что в студии невозможно построить сколько-либо значительный проект, состоящий больше чем из пары-тройки project files.

[ltwood.livejournal.com]

100% + см. мой ответ ниже...

[ltwood.livejournal.com]

1. Портабельность -- под win32 я компилируюсь gcc из mingw и бесплатно имею перносимость между win32 и *nix .
2. Объективно удобнее -- плагины к far'у после некоторой настройки придают его редактору многие черты, отсутствующие в VS.
3. То же, что в п.2 -- использование портированных из *nix утилит дает в руки мощь, совершенно недоступную в VS. Причем именно благодаря возможности комбинировать отдельные простые инструменты посредством sh (хотя у сижу под ублюдочным cmd).
4. Независимость инструментальной оболочки (редактор, sh, утилиты) от языка (я одинаково часто работаю с исходниками на C++, awk, python, LaTeX).
5. Инструментальная оболочка остается открытой -- если мне чего-то не хватает, то я просто пишу на C++/awk/python нужную мне утилиту.
6. Сборка больших проектов из многих подсистем со сложными взаимосвязями подсистем. Особенно в случае, когда одновременно поддерживается множество проектов, пересекающихся по некоторым подсистемам.