Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
MSH, Microsoft’s new Command Line Interface (CLI), will allow commands to interact on a much deeper level than was previously available. Developers can work with results of other commands as well as provide an interface for other commandlets to use output as their input. This article gives examples of the input, output, and throughput in C#.
Introduction to Command Shell Communication
In order to understand communication between commandlets, imagine you have two types of commands, analogous to a water pump and a reservoir. Between these two objects, you have a pipe. The water pump is your data generator. It can take whatever parameters it is passed, and in turn generate data (water) to be passed on. The pipe is what allows the water to flow into the reservoir, and be used however the reservoir sees fit. Under MSH, the pipe is easy to code.
Practical Uses For Piping
Piping is very convenient for helping to compartmentalize reused pieces of functionality on the commandline. For example, if a commandlet is very efficient at searching through results for a specific fuzzy text match (See http://www.merriampark.com/ld.htm for many examples of Levenshtein distance fuzzy matching), it would be very intuitive to separate the initial commandlet’s “pumped” data through the pipe into a search commandlet for more processing, and out to a final commandlet for formatting.
Simple Syntax For Piping
Pipes can be used to actually stream data back and forth between commandlets through the pipe, or used in parallel, to take the results of one commandlet to be used as the input for the second. For our example in the companion code, we’ll use the following syntax:
out/reservoir (get/waterpump)
This will allow the verb/noun commandlet pair “out/reservoir” to use the results of the get/waterpump commandlet’s execution. In this case, we are building on the example used in the first article in this series on creating an MSH commandlet.
Pipe Out to Another Commandlet
Piping data out from a commandlet is as simple as writing out your objects to the output stream. This can be achieved simply by using either the WriteObject or WriteObjects classes. The command shell does the work of actually streaming and synchronizing the data to the destination commandlet. Microsoft has allowed for as many piped commandlets as the user wants to toss at it, which leaves the door open for some very complex shell scripts.
Pipe In from Another Commandlet
Piping in from another commandlet is very easy as well. Through the use of attributes, as seems to be the trend with much of the new functionality, MSH allows the developer to simply say what is allowed to retrieve data from the pipeline to give to other commandlets. The parameter syntax below shows the ease with which one can bring in data:
//private variable for param
private string myParameter=null;
//PUBLIC ACCESSOR FOR myParameter
[ParsingParameterDeclaration]
[ParsingAllowPipelineInput]
[ValidationSet("PossibleParam1","PossibleParam2")]
public string MyParameter
{
get
{
return myParameter;
}
set
{
myParameter = value;
}
}
Notice the use of the ParsingAllowPipelineInput attribute to let the code bring in data from other sources, and the ValidationSet attribute for integrity checks on that data. There is also the attribute ValidationRange for simple data types where values must be between two other values. These, as well as a plethora other attributes, come prepackaged into the shell to allow for centralized handling. In addition to the many attributes is an expansive list of verbs to be used to extend the base functionality of newly created apps. Some of the additional functionality is added through the presupplied “whatif” parameter. This allows the enduser to go through the process of writing and running the scripts in an environment that is exactly the same as the real world execution, with the exception that the results of the script are not actually saved. In the example shown at Microsoft’s PDC Conference 2003 this past October, this resulted in a script that showed the latest Microsoft Knowledge Base updates that the end user was thinking of applying. It went through the process of showing all of the output for the commands that were run by the user without actually doing any of the physical installation.
The out/reservoir commandlet uses the output of the ProcessRecord() method to pull in as input.
WriteObject("MACHINE")
The Reservoir’s ProcessRecord method allows the commandlet to display either the machine name and OS information, or the environment variables, depending upon the input. The WaterPump will always ask for the machine information.
Final Thoughts
Microsoft’s pipeline for commands at the shell level is much improved over that of DOS in years past. The developer of shell commands has been given much more leverage to write commands that have been separated by task and can be reused much more easily than commands written for DOS. The single best feature of the shell is the added parameters provided for error handling, forcing commands to run, and allowing users to run commandlets with completely different sets of security credentials. There are specifically added-in methods to allow the developer to get additional information from the user, whether through the time-tested prompt at the commandline, to bringing up authentication GUI messageboxes.
The result for all of this added technology is really to put more tools in the hands of the developers for the shell. Microsoft really seems to have gone out of their way to spurn a great deal of the criticism that has been attracted to Windows by users of richer shells, whether for Unix/Linux or other operating systems. Whether through looping and piping to create complex scripts to make a system administrator’s job easier, or through custom commandlet development, MSH lets the organization determine what their tools will be able to do. It seems that initially, though, a critical mass will be necessary to start a resource site where people can freely share their custom commandlets, but for now, anyone proficient in the languages of .NET will be able to create simple commandlets.
Downloads
Source code: MSHArticle3.zip – 2 kb
# # #
