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:
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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.:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
<# .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:
1 2 3 |
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.