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

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.