Прежде всего, я надеюсь, что не дублирую другой пост. В таком случае я немедленно удалю.
Я просмотрел многие вопросы / ответы на этом веб-сайте, пытаясь найти, какой язык сценариев мне следует использовать, и я вижу, что многие люди рекомендуют PowerShell, особенно если они совершенно не знакомы со сценариями, как я.
Среда, в которой я работаю, составляет около 150 машин с различными ОС MS от XP до Server 2008 R2 Enterprise.
Я вижу, что один из моих коллег использует CSSCRIPT во многих своих делах ... и мы называем его королем сценариев. Он настолько запомнил код, что даже не знает никаких хороших предложений, кажется, о том, как я могу его выучить или какой язык сценариев подойдет мне лучше всего.
Я смотрю на PowerShell, как я уже сказал, поскольку другие сообщения, кажется, предполагают это. Я не хочу, чтобы мои скрипты работали на всех 150 машинах. Я хочу иметь возможность удаленно запускать скрипт, который перемещает файлы, обновляет файлы, собирает информацию о машинах и их реестрах, другую различную информацию и т. Д.
Что предлагается между этими двумя языками сценариев или любыми другими (поскольку я буквально новичок в этом и хочу изучить)?
Прошу прощения, если это дубликат. Я не мог найти ничего по этому конкретному вопросу, но многие очень и очень тесно связаны.
Если вы работаете в среде Microsoft, то ответ - Powershell.
Powershell является практически обязательным требованием для администраторов Microsoft в будущем. Он предназначен для замены и замены VBscript во всех отношениях.
Не говоря уже о том, что это, по сути, самое потрясающее, что сделал MS ... может быть, когда-либо!
На ваш вопрос о том, что ваш коллега использует для написания сценариев - я не знаю "csscript", но я знаю, что "cscript" - это версия командной строки хоста сценариев VBScript. Так что, возможно, вы смотрите на VBscript. Это также очень популярный язык сценариев Microsoft. Но он не такой современный, как Powershell.
Чтобы добавить к ответу Райана, в будущем возможности сценариев Powershell являются частью Microsoft CEC (Common Engineering Criteria), что означает, что все продукты MS, выпущенные в будущем, должны предоставлять некоторые возможности сценариев Powershell.
Многие продукты приняли это близко к сердцу, в VMM все администрирование осуществляется через Powershell. Фактически, графический интерфейс просто создает сценарии PowerShell для реализации действий, которые вы просили выполнить. В Exchange 2007 и 2010 есть административные действия, которые можно выполнять ТОЛЬКО через Powershell (конечно, это не очень распространенные действия).
Преимущества Powershell заключаются в том, что он построен на .Net и имеет доступ ко всем возможностям .Net (вы часто можете использовать примеры C #, чтобы выяснить, как делать что-то непосредственно из .Net в Powershell).
Вместо того, чтобы передавать текст через конвейер, вы передаете полностью сформированные объекты, позволяя командлетам дальше по конвейеру получить доступ ко всем свойствам и методам объекта, не заботясь о них ни одним из промежуточных командлетов. Это также может сделать код многоразовым.
Наконец, Powershell ориентирован на администраторов, а не на разработчиков. Стандарты PowerShell позволяют администраторам довольно интуитивно открывать язык и возможности, при этом предоставляя разработчикам и опытным разработчикам сценариев доступ ко всем базовым функциям. В идеальном мире у вас был бы командлет для выполнения всех небольших задач, которые необходимо было выполнить, а там, где его не было, вы могли бы либо написать его через доступ PowerShell к .Net, непосредственно в .Net в виде командлета или найти разработчика, который сделает то же самое.