Прежде всего, я надеюсь, что я не дублирую другой пост. Если так, я немедленно удалю.
Я просмотрел многие вопросы / ответы на этом веб-сайте, пытаясь найти, какой язык сценариев мне следует использовать, и я вижу, что многие люди рекомендуют 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 в виде командлета или найти разработчика, который сделает то же самое.