Command-line interface or PowerShell?

Question

If you were to make a tool that:

1. sys-admins would use (e.g. system monitoring or backup/recovery tools)
2. has to be script-able on Windows

Would you make the tool:

1. A command-line interface tool?
2. PowerShell cmdlet?
3. GUI tool with public API?

I heard PowerShell is big among sys-admins, but I don't know how big compared to CLI tools.

Answer 1

Python.

Ideally suited for command-line applications and system administration. Easier to code than most shells. Also, runs faster than most shells.

Answer 2

PowerShell.

With PowerShell you have your choice of creating reusable commands in either PowerShell script or as a binary PowerShell cmdlet. PowerShell is specifically designed for commmand line interfaces supporting output redirection as well as easily launching EXE's and capturing their output. One of the best parts about PowerShell IMO is that it standardizes and handles parameter parsing for you. All you have to do is declare the parameters for your command and PowerShell provides the parameter parsing code for you including support for typed, optional, named, positional, mandatory, pipeline bound, etc. For example, the following function declarations shows this in action:

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 advanced functions provide even more capabilities such as parameter aliases -CN alias for -ComputerName, parameter validation [ValidateNotNull()] and doc comments for usage and help e.g.:

<#
.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
    )
    ...
}

See how the attributes give you finer grained control over PowerShell's parameter parsing engine. Also note the doc comments that can be used for both usage and help like so:

AdvFuncToProcessPaths -?
man AdvFuncToProcessPaths -full

This is really quite powerful and one of the main reasons I stopped writing my own little C# utility exes. The parameter parsing wound up being 80% of the code.

Answer 3

I always create a command line tool first:

• It is far easier to automate / incorporate into scripts than a GUI (much less work than producing an API)
• It will run in pretty much all windows machines (including older machines without Power shell installed)

Although power shell is a great tool for sysadmins, I don't yet think it is widely spread enough to escape the need to also produce a traditional command line tool as well - hence I always make a command line tool first (although I might also choose to go onto produce a PowerShell cmdlet).

Similarly, although a well thought out API may be easier for scripting, your API will place restrictions on what languages users can script in and so it is always a good idea to additionally provide a command line tool as a fallback / easy alternative.