Рекомендации для сценариев Windows XP, WSH против PowerShell

Question

После большого опыта написания сценариев в мире открытого исходного кода Unix / Linux с использованием таких языков, как Bourne Shell, Perl, Python и Ruby, я теперь обнаружил, что мне нужно заняться сценариями администрирования Windows XP. Похоже, что устаревшей средой является Windows Script Host (WSH), который может использовать различные языки сценариев, но основным языком является VBScript, и он основан на COM-объектах. Однако в будущем, похоже, появится Windows PowerShell, основанная на .NET.

Я не занимался базовым с Applesoft в 1970-х годах, поэтому я не заинтересован в изучении VBScript, хотя научился достаточно писать небольшой скрипт для подключения сетевых дисков. Если я собираюсь потратить время на то, чтобы по-настоящему научиться этому, я склоняюсь к тому, чтобы инвестировать свое время в среду .NET PowerShell, если это действительно будущее. Пару лет назад я занимался программированием на Windows Forms на C #, поэтому немного знаком с .NET, что также делает PowerShell привлекательным.

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

Обновление: В итоге я использовал WSH / VBScript для определенного сценария, который я устанавливаю в качестве сценария запуска на рабочих станциях Windows XP пользователя. Все, что мне нужно сделать, это скопировать его в папку «Автозагрузка», и все готово. Однако я только выучил достаточно WSH, чтобы выполнить эту работу. Я рад видеть, что PowerShell - это будущее, и когда у меня возникнут более сложные задачи сценариев, я перейду к PowerShell.

Answer 1

Стоит ли это?

Абсолютно. Вот несколько причин, почему.

1. Все больше и больше продуктов Microsoft основаны на PowerShell - например, Exchange Server 2007, SQL Server 2008 и т. Д.
   
2. PowerShell может получить доступ к Microsoft .NET.
3. Простота в изучении - вам нужно всего несколько команд для изучения возможностей PowerShell - например, Get-Command, Get-Help, Get-Member и т. Д.
4. Большинство команд имеют псевдонимы и отображаются так, как они похожи на команды оболочки DOS или * NIX - например, "ls" и "dir" являются псевдонимами для "Get-ChildItem", "cd" для "Set- Расположение "
5. Это отличный инструмент разработчика - поскольку PowerShell может обращаться к библиотеке .NET, вы можете создать прототип некоторых своих функций .NET в PowerShell
6. Вы можете перемещаться по Реестру, Сертификату, Переменным среды и т. Д., Как если бы они были файловой системой. Для перемещения по ней вы используете ту же команду, что и в FileSystem - например, cd HKLM: \

Недостатки:

1. PowerShell версии 1.0 не поддерживает удаленное взаимодействие (поддерживается в 2.0) и создание нового потока (с использованием System.Threading.Thread, но поддерживает фоновые задания в 2.0)
   
2. Кривая обучения может быть долгой, если вы не привыкли к C # / языку Java.
   
3. Трудно создавать общие объекты .NET
   • например.) Создание общей коллекции List<int> похоже на

$ l = new-Object System.Collections.Generic.List``1 [[System.Int32]]

Answer 2

Powershell - это определенно правильный путь, если вы склонны смотреть в будущее, но его нужно устанавливать отдельно в Windows до 7, что может сделать WSH более привлекательной целью, если вы просто хотите развернуть сценарии, которые выполняются без дополнительных зависимостей. Кроме того, .NET еще не включена в древние версии Windows, такие как XP, что еще больше повышает планку.

Если у вас был опыт работы с .NET, вы должны найти Powershell довольно интуитивно понятным. И особенно в средах Windows Server, он, по-видимому, быстро становится стандартным для администрирования из командной строки, поскольку почти все недавно выпущенные серверные компоненты поставляются с пользовательскими командлетами Powershell. Похоже, Powershell - это путь для Microsoft, которому они хотят какое-то время следовать. Черт возьми, они до сих пор даже не хоронили COM, поэтому я ожидаю, что Powershell будет жить как минимум на десять лет дольше, поскольку они позиционируют его как среду автоматизации и создания сценариев для административных задач.

Также я нашел объектный конвейер, хотя мне потребовалось некоторое время, чтобы привыкнуть к нему, очень мощный и простой в использовании в конце. Конечно упрощает многие вещи, которые требуют sed / awk на * nixes.

При этом я все еще использую пакетные файлы Windows для многих вещей, которые должны работать в Windows без каких-либо дополнительных зависимостей, но это просто моя грязная привычка:)

Answer 3

Основным преимуществом WSH является то, что он устанавливается по умолчанию начиная с Windows 98, возможно, даже с Windows 95, но поскольку PowerShell поставляется с Server 2008 сейчас и его можно устанавливать на любом компьютере после XP, он становится менее проблематичным. *

Если у вас есть полный контроль над серверами, на которых будут выполняться ваши сценарии, я бы рекомендовал использовать PowerShell.

Answer 4

Я долго искал лучший язык сценариев для Windows (и продолжаю его делать). Однако, после просмотра всех вариантов, я получаю JScript для WSH. Хотя Powershell явно имеет свои преимущества, преимущества первого поста кажутся несущественными (кроме встроенной IDE). Недостатки, однако, не полностью перечислены:

1. Прежде чем вы сможете запустить скрипт, вы должны вручную включить возможность их запуска, что делает развертывание на распределенном Сеть намного сложнее, чем с WSH.
2. Соглашение об именовании для командлетов. Это не camelCase и не python_tail. Это буквально жжет мне глаза.
3. Имена переменных начинаются с $ (я думаю, в стиле Perl? Точно не знаю) - то же самое и здесь.
4. Вы не можете использовать реальные пути для запуска сценариев.

Напротив, JScript более C-подобен, не требует явного включения запуска скрипта, принимает относительные пути, чувствителен к регистру и свободно печатается (оба являются преимуществами IMHO для языка сценариев по сравнению с VBScript). Я не очень разбираюсь в PowerShell, только то, что я нашел в MS Technet и в сети.

Так что для меня две основные причины, по которым я отказался от PowerShell (даже зная, что он, вероятно, более мощный, и MS активно его поддерживает), заключались в следующем: 1) то, что вы должны вручную включить возможность запуска сценариев на каждой машине; вид, к которому я привык (и не только я, я думаю).

Answer 5

Теперь мы находимся в 2017 году, и, оглядываясь назад, похоже, что Powershell был хорошим выбором, ИМХО.

Answer 6

Используйте Posershell, если это возможно, и встроенный C #, если нет - WSH, нет? - msdos-batch.