Совет для Windows XP Scripting, WSH и PowerShell

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

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

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

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

ОТВЕТЫ

Ответ 1

Это "стоит"?

Совершенно верно. Вот несколько причин.

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

Недостатки:

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Итак, для меня две основные причины, по которым я отказался от powershell (даже зная, что он, вероятно, более мощный, и MS, активно поддерживающий его): 1) что вам нужно вручную включить возможность запуска script на каждой машине 2) General non C как я привык (и не только я, я думаю).

Ответ 5

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

Ответ 6

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