Какую проблему удалось решить MS, создав PowerShell?

Я спрашиваю, потому что PowerShell меня смущает.

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

a) Позвольте вам заглянуть и подтолкнуть в сборках .NET в командной строке (почему это является причиной для существования PowerShell?)

b) Для размещения в .NET-приложениях для автоматизации, подобных DCOP в KDE, и как Gnome использует CORBA.

c) следует рассматривать как ".NET script", а не как действительную оболочку (связанную с b).

Мне всегда казалось, что Windows не хватало достойного способа выпустить скрипты автоматизации. cmd слишком упрощен во многих случаях, и WSH слишком тупой (хотя комбинация может быть успешно использована, я не поклонник). Когда я впервые услышал о PowerShell, я почувствовал, что Windows наконец-то получила достойную оболочку, которая сможет помочь с автоматизацией многих задач, но недавний опыт и мой коллега говорят мне иначе.

Чтобы быть ясным, я не понимаю, что он построен на .NET, или что он передает объекты, а не текст (несмотря на мой фон Unix:]), и я не утверждаю, что PowerShell бесполезно, но из того, что я вижу, он не решает проблему, я надеялся, что это решится очень хорошо. Как только вы выйдете за пределы мира .NET/Powershell, все перестанет быть приятным и приятным для вас.

Итак, с учетом всего этого, какая проблема решала MS, создавая PowerShell, или это какой-то политический ублюдок, как я подозреваю? Я googled и не ударил ни о чем, что достаточно ответил, что для меня, но чем больше цитат, тем лучше.

Ответ 1

PowerShell был фактически построен как несколько вещей: зрелая и расширяемая платформа автоматизации и современная оболочка администрирования.

Первый используется в основном для графиков GUI для Exchange и других серверных продуктов последнего времени. Графический интерфейс - это всего лишь оболочка PowerShell, которая делает тяжелый подъем (вроде программ UNIX GUI, которые становятся оболочкой для программы командной строки).

Джеффри Сновер (изобретатель PowerShell) немного разъясняет о том, как была создана PowerShell, с какими целями и проблемами он должен решить.

На мой взгляд, PowerShell как оболочка явно предназначена для замены cmd (легко видеть) и Windows Script Host (Windows Script Хозяин не получал много внимания в последние годы, хотя в свое время у него были аналогичные концепции, такие как .NET. [Одна платформа, несколько языков с ActiveScripting], но с .NET Microsoft в основном ставит это для отдыха и воскрешение, вероятно, не было для них вариантом).

Он объединяет большинство аспектов администрирования Windows в общих понятиях и методах, которые вам нужно изучить только один раз. Кроме того, мощь PowerShell для меня сильно связана с тем, что она обходит объекты, которые могут объяснить, почему вы сталкиваетесь с проблемами при выходе из мира .NET/PowerShell, где вы получаете только String[] из команды. Но для многих вещей, которые вы бы назвали внешней программой для cmd, есть командлет, который сделает это за вас.

Ответ 2

Как разработчик, я могу сказать, что у меня больше нет кучи проектов ConsoleApplication42, лежащих в папке.

Как разработчик в небольшой компании, где я в значительной степени делаю все, что нужно ИТ (DBA, манипулировать маршрутизаторами, извлекать записи о деталях звонков с коммутатора, контролировать и распределять пропускную способность для клиентов и т.д.). Я могу сказать вам, что PowerShell заполняет крайне необходимый промежуток в Windows и тот факт, что он построен на .NET, обеспечивает плавный путь обновления, когда конвейер PowerShell слишком медленный, чтобы обрабатывать миллионы итераций или требуется более постоянная, строго типизированная реализация.

В любом случае, я думаю, вопрос в том, почему вы переходите на PowerShell, если у вас нет насущной необходимости? Я имею в виду, что хорошо изучить его сейчас, поскольку это в основном новый интерфейс управления для всех вещей Microsoft. Но если это не влияет на вас, тогда не беспокойтесь, если вы не думаете, что получаете что-то.

EDIT (в ответ на комментарии ниже)

Похоже, вы пытаетесь использовать класс .NET Process для запуска exe и перенаправления его stdout, чтобы он мог быть прочитан вызывающим. Я согласен, что это боль в .NET, но, к счастью, PowerShell делает все это для вас довольно просто. Что касается захвата результата и записи его на дисплей, это довольно просто, хотя команда не очень известна, потому что она часто не используется. Вот пример:

# I always find it easier to use aliases for external commands
Set-Alias csc C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe

# Create some source file
Set-Content test.cs @"
class Program {
    static void Main() {
        System.Console.WriteLine("Hello World");
    }
}
"@

# Call CSC.EXE
# the output of csc.exe is written to results.txt and piped
# to the host (or select-string if you prefer)
csc test.cs | Tee-Object -file results.txt

# Check for errors
if ($LASTEXITCODE) { 
    # this is where community extensions would come in
    # handy. powershell 2.0 also has a command to send
    # mail but in 1.0 you can grab one from poshcode.org
}

Ответ 3

IMHO основным преимуществом является разумная вырезка и вставка в консоль.

В противном случае я использую ActiveState ActivePerl для сценариев в Windows. Это более мощный инструмент, чем любая оболочка Windows script, а интерфейс OLE предоставляет весь Windows API в удобном для использования способом.