Совет для 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 был хорошим выбором, ИМХО.