2010-07-23 3 views
4

Если вы должны были сделать инструмент, который:Интерфейс командной строки или PowerShell?

  1. сисадмин будет использовать (например, мониторинг системы или резервное копирование/инструменты восстановления)
  2. должен быть скрипт-состояние на Windows,

бы вы делаете инструмент:

  1. Инструмент интерфейса командной строки?
  2. Командлет PowerShell?
  3. GUI-инструмент с открытым API?

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

+1

btw, powershell - это де-факто инструмент CLI. – x0n

ответ

11

PowerShell.

С помощью PowerShell у вас есть выбор для создания многоразовых команд в сценарии PowerShell или в виде двоичного командлета PowerShell. PowerShell - это, специально предназначенный для интерфейсов линии связи, поддерживающих перенаправление вывода, а также возможность запуска EXE и их выход. Одна из лучших частей в PowerShell IMO заключается в том, что она стандартизирует и обрабатывает парсинг параметров для вас. Все, что вам нужно сделать, это объявить параметры для вашей команды, а PowerShell предоставляет код анализа параметров для вас, включая поддержку типизированных, необязательных, именованных, позиционных, обязательных, связанных с конвейером и т. Д. Например, следующие объявления функций показывают это в действии :

function foo($Path = $(throw 'Path is required'), $Regex, [switch]$Recurse) 
{ 
} 

# Mandatory 
foo 
Path is required 

# Positional 
foo c:\temp '.*' -recurse 

# Named - note fullname isn't required - just enough to disambiguate 
foo -reg '.*' -p c:\temp -rec 

PowerShell 2.0 расширенные функций обеспечивают еще больше возможностей, такие как параметры псевдонимы -CN alias for -ComputerName, проверки параметров [ValidateNotNull()] и док комментарии для использования и помощи, например:

<# 
.SYNOPSIS 
    Some synopsis here. 
.DESCRIPTION 
    Some description here. 
.PARAMETER Path 
    The path to the ... 
.PARAMETER LiteralPath 
    Specifies a path to one or more locations. Unlike Path, the value of 
    LiteralPath is used exactly as it is typed. No characters are interpreted 
    as wildcards. If the path includes escape characters, enclose it in single 
    quotation marks. Single quotation marks tell Windows PowerShell not to 
    interpret any characters as escape sequences. 
.EXAMPLE 
    C:\PS> dir | AdvFuncToProcessPaths 
    Description of the example 
.NOTES 
    Author: Keith Hill 
    Date: June 28, 2010  
#> 
function AdvFuncToProcessPaths 
{ 
    [CmdletBinding(DefaultParameterSetName="Path")] 
    param(
     [Parameter(Mandatory=$true, Position=0, ParameterSetName="Path", 
        ValueFromPipeline=$true, 
        ValueFromPipelineByPropertyName=$true, 
        HelpMessage="Path to bitmap file")] 
     [ValidateNotNullOrEmpty()] 
     [string[]] 
     $Path, 

     [Alias("PSPath")] 
     [Parameter(Mandatory=$true, Position=0, ParameterSetName="LiteralPath", 
        ValueFromPipelineByPropertyName=$true, 
        HelpMessage="Path to bitmap file")] 
     [ValidateNotNullOrEmpty()] 
     [string[]] 
     $LiteralPath 
    ) 
    ... 
} 

Посмотрите, как атрибуты дают вам тонкоуровневый контроль OV er PowerShell. Также обратите внимание на комментарии DOC, которые могут быть использованы как для использования и помогают выглядеть примерно так:

AdvFuncToProcessPaths -? 
man AdvFuncToProcessPaths -full 

Это действительно очень мощное и одна из главных причин, почему я перестал писать свои собственные мало C# подсобных EXEs. Параметр синтаксического анализа оказался на 80% от кода.

+2

Если Windows является целью, я, честно говоря, не думаю, что есть лучшая альтернатива, чем PowerShell. Лично я считаю, что его самая большая сила заключается в том, как легко это делает удаленный доступ. Я ненавижу дистанцирование, поскольку по моему опыту всегда был процесс, который вы должны были выполнить, прежде чем вы могли бы начать его, что потребовалось просто. Теперь с PowerShell все, что вам нужно сделать, это «Enable-PSRemoting», и вам хорошо идти. –

+0

Да, есть * много *, чтобы понравиться в PowerShell, включая удаленный доступ, но мой ответ уже получил вид долго. :-) –

-1

Python.

Идеально подходит для приложений командной строки и системного администрирования. Легче кодировать, чем большинство оболочек. Кроме того, работает быстрее, чем большинство оболочек.

+0

Да, но не интегрирован (или легко интегрируется) с программным обеспечением ms. – x0n

+0

@ x0n: Что? У вас есть особенности в этом? Это новости для меня и для всего сообщества IronPython. –

+0

хмм; колено рывок ответ от вас думаю. Я не говорю, что грамматически powershell является лучшим langauge (это не так), но в других терминах: содержит ли общие требования к инженерным критериям Microsoft (CEC), что все продукты Microsoft должны поддерживать языковые привязки и/или интегрированную поддержку для ironpython? Нет. Это для powershell. – x0n

0

Я всегда создаю инструмент командной строки первой:

  • Это гораздо проще автоматизировать/включать в сценарии, чем GUI (гораздо меньше работы, чем производя API)
  • Он будет работать в значительной степени все машины для окон (включая старые машины без установленной оболочки питания)

Хотя силовая оболочка - отличный инструмент для системных администраторов, я пока не думаю, что она широко распространена, чтобы избежать необходимости также создавать традиционную командную строку инструмент также - следовательно, я всегда сначала создавайте инструмент командной строки (хотя я мог бы также пойти на создание командлета PowerShell).

Аналогичным образом, хотя хорошо продуманный API может быть проще для написания сценариев, ваш API будет устанавливать ограничения на то, на каких языках пользователи могут запускать скрипты, и поэтому всегда полезно добавить инструмент командной строки в качестве резервной/простой альтернатива.

Смежные вопросы