Советы для сценариев Windows XP, WSH и PowerShell
После большого опыта написания сценариев в мире Unix / Linux с открытым исходным кодом, используя такие языки, как Bourne Shell, Perl, Python и Ruby, мне теперь нужно сделать некоторые сценарии администрирования Windows XP. Похоже, что устаревшей средой является Windows Script Host (WSH), который может использовать различные языки сценариев, но основным языком является VBScript и основан на COM-объектах. Однако будущее, по-видимому, за Windows PowerShell, которая основана на .NET.
Я еще не закончил. Basic с Applesoft в 1970-х годах, поэтому я не стремлюсь изучать VBScript, хотя я узнал достаточно, чтобы написать небольшой скрипт для монтирования сетевых дисков. Если я собираюсь потратить время, чтобы действительно изучить это,я склоняюсь к тому, чтобы инвестировать свое время в среду .NET PowerShell, если это действительно будущее. Пару лет назад я занимался программированием на C# Windows Forms, поэтому у меня есть некоторое представление о .NET, что также делает PowerShell привлекательным.
Понимание того, что ни у кого нет хрустального шара, чтобы спрогнозируйте будущее Microsoft, я хотел бы услышать от любого, кто является пользователем PowerShell и считает, что это стоит, или если есть кто-то, кто знает о серьезных недостатках PowerShell, и рекомендует мне держаться от него подальше.
Обновление: в итоге я использовал WSH/VBScript для конкретного сценария, который я устанавливаю в качестве сценария запуска на рабочих станциях Windows XP пользователя. Все, что мне нужно сделать, это скопировать его в папку запуска, и я закончу. Однако я узнал достаточно WSH, чтобы выполнить эту работу. Я рад видеть, что PowerShell-это будущее, и когда у меня будут более сложные задачи по написанию сценариев, я обращусь к PowerShell.
6 ответов:
Стоит ли оно того?
Абсолютно. Вот несколько причин, почему.
- все больше и больше продуктов Microsoft основаны на PowerShell-например, Exchange Server 2007, SQL Server 2008 и т. д.
[9]] PowerShell может получить доступ к Microsoft. NET.
- легко учиться - вам нужно всего несколько команд, чтобы изучить возможности PowerShell-например) Get-Command, Get-Help, Get-Member и т. д.
- большинство команд имеют псевдонимы и сопоставлены таким образом, что они являются аналогично командам DOS или * Nix оболочки-например) " ls " и " dir "являются псевдонимами для " Get-ChildItem", "cd"для" Set-Location "
- это отличный инструмент разработчика-поскольку PowerShell может получить доступ к библиотеке .NET, вы можете создать прототип некоторых функций .NET в PowerShell
- Вы можете перемещаться по реестру, сертификату, переменным окружения и т. д., как если бы они были файловой системой - вы используете ту же команду, что и в файловой системе для перемещения - например) cd HKLM:\
Недостатки:
PowerShell версии 1.0 не поддерживает удаленное взаимодействие (поддерживается в версии 2.0)и создание нового потока (с помощью System.Нарезка резьбы.Thread, но будет поддерживать фоновые задания в 2.0)
- кривая обучения может быть длинной, если вы не привыкли к языку на основе C# / Java
- трудно создавать универсальные объекты .NET
- например, создание общей коллекции
List<int>похоже на следующее$л = новый-системный объект.Коллекции.Универсальный.Список`1[[Система.Типа int32]]
Powershell-это, безусловно, правильный путь, если вы склонны смотреть вперед, но он должен быть установлен отдельно в Windows до 7, что может сделать WSH более привлекательной целью, если вы просто хотите развернуть сценарии, которые выполняются без дополнительных зависимостей. Кроме того, .NET еще не включен в древние версии Windows, такие как XP, что еще больше поднимает планку.
Если вы имели некоторое представление о .NET, вы должны найти Powershell довольно интуитивно понятным, однако. И особенно в средах Windows Server это по-видимому, он быстро становится стандартным для администрирования командной строки, поскольку почти все недавно выпущенные серверные компоненты поставляются с пользовательскими командлетами Powershell. Таким образом, Powershell, похоже, является путем для Microsoft, которому они хотят следовать в течение некоторого времени. Черт возьми, они даже не похоронили COM так далеко, поэтому я ожидаю, что Powershell проживет по крайней мере на десятилетие дольше, поскольку они позиционируют его как среду автоматизации и сценариев для административных задач.
Также я нашел объектно-ориентированный конвейер, в то время как он занял мне нужно некоторое время, чтобы привыкнуть к нему, очень мощному и простому в использовании в конце концов. Безусловно, упрощает многие вещи, которые требуют sed/awk на * nixes.
Тем не менее, я все еще использую пакетные файлы Windows для многих вещей, которые должны работать на Windows без каких-либо дополнительных зависимостей, но это просто моя грязная привычка:)
Главное преимущество WSH заключается в том, что он был установлен по умолчанию начиная с Windows 98, возможно, даже Windows 95, но поскольку PowerShell теперь поставляется с сервером 2008 и может устанавливаться на что угодно после XP, это становится менее проблематичным.
Если у вас есть полный контроль над серверами, на которых будут выполняться ваши сценарии, я бы рекомендовал использовать PowerShell.
Я уже давно ищу лучший язык сценариев для Windows (и до сих пор ищу). Однако после просмотра всех вариантов я получаю JScript для WSH. В то время как Powershell явно имеет преимущества, Преимущества от первого сообщения кажутся незначительными (за исключением встроенной IDE). Недостатки, однако, не полностью перечислены:
- Перед запуском скрипта необходимо включить его вручную. возможность запускать их, что делает развертывание на распределенном сеть намного сложнее, чем с WSH.
- соглашение об именовании командлетов. Это не верблюжьего, ни python_tail. Он буквально обжигает мне глаза.
- имена переменных начинаются с $ (Perl-стиль, я думаю? не знаю точно) - то же самое и здесь.
- Вы не можете использовать реальные пути для запуска сценариев.
Напротив, JScript более похож на C, не требует явного включения запуска скрипта, принимает относительные пути, чувствителен к регистру и слабо типизирован (оба являются преимуществами IMHO для языка сценариев, по сравнению с язык VBScript). У меня не так много знаний в PowerShell, только то, что я нашел на MS Technet и в сети.
Итак, для меня две основные причины, по которым я отказался от powershell (даже зная, что он, вероятно, более мощный и MS активно поддерживает его), были: 1) что вы должны вручную включить возможность запуска скрипта на каждой машине 2) Общий не похожий на C вид, к которому я привык (и не только я, я думаю).