Command-line interface or PowerShell? - command-line

Question

If you were to make a tool that:
sys-admins would use (e.g. system monitoring or backup/recovery tools)
has to be script-able on Windows
Would you make the tool:
A command-line interface tool?
PowerShell cmdlet?
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.

Answer 2

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.

Answer 3

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