Making the Command Line Cool Again
I worked on Unix systems for probably close to a decade before coming to work at Microsoft. The common denominator among them all was that the command line was way more interesting than whatever GUI they might provide (the two exceptions being the NeXT cube and SGI's IRIX which were years ahead of their time). My perspective was a bit biased being a programmer since scripting at the command line brought me an efficiency and range of functionality that could not be met with any point and click GUI. Simply put, it was way cooler to get things done with the command line than any pretty boy UI. For these reasons, I became acquainted with dozens of command line scripting options and expert in more than a few.
Bourne Shell and all its brethren are where it started for me: ksh, sh, Bash, zsh, etc. Writing scripts that could work on a variety of systems to automate a bunch of manual tasks. In that environment you don't learn one tool, you have to learn several to get anything useful done: grep, awk, sed, ps, kill, ls, sort, uniq, count, more, etc. You master the syntax of the input/output of each of these commands as well as the format of all the useful files. The mantra that everything is a file in Unix serves you well as long as you (a) know where that file is and (b) know the structure of the file.
This was tedious but it worked. The tedium came from learning a bunch of tools and how to string them together as well as how to work around the idiosyncrasies of these tools on all the different flavors of *nix. Then came the most wonderful invention: Perl. Hard to believe that it has been twenty years already! Perl was wonderful because it replaced all those tools and gave you a consistent regex notation for parsing all those text files. Perl 4 still sets the bar for maximum functionality in minimal lines of code. Perl 5 raised the bar by creating a vast library of re-usable modules to handle all those common administrative tasks and more. No more re-inventing the wheel over and over again.
Perl has an elegance to it once you grok the syntax. You can work some real magic with Perl hash tables and dynamic evaluation. Perl is never going to win any beauty prizes though. For some folks, it's just not their cup of tea. Python could be viewed as an alternative to Perl for those who prefer a more "pure" scripting language. I first came into contact with Python while working at NASA. There are some incredibly brilliant Python folks there. I love the way Python handles objects (though my favorite is the original prototype concept in JavaScript). Python too has a vast library of re-usable modules. Some would argue that the way Python handles libraries is cleaner than Perl but they both get the job done.
Fast forward to when I joined Microsoft six years ago. Love the interface of Windows compared to X Windows, but when it came to command line scripting, it was like going back to the dark ages. Not a big fan of cmd.exe or the WSH but it does get the job done. Partly because of past history I turned to ActivePerl to fill my scripting needs on the Windows platform. It's an awesome product but using Perl on Windows always leaves you feeling like something is missing. Part of the problem is that everything is not a file on Windows. Management in Windows means understanding other things like WMI, Active Directory, COM, etc. The other part of the problem is that Windows fundamentally handles file paths differently and it can be a hard transition from using Perl on Unix to using Perl on Windows. Using the command line in Windows was definitely not cool.
This all changes with PowerShell. I was skeptical at first. Could Microsoft really create something that could compete with Perl or Python and fill this aching gap in their command line story? I think the PowerShell folks have done just that. They've borrowed a lot of the great concepts from those languages while introducing some novel concepts of their own. First off, I can do things in PowerShell with about the same number of lines of code I would use in Perl. Secondly, I can leverage the entire functionality of the .NET framework. Re-read that again. I can't overstate the importance of this piece. No more re-inventing the wheel here. There is a ton of functionality in those libraries that you can use directly in PowerShell without having to learn any new syntax. For example, retrieving a file from a remote HTTP server is trivial and you don't have to know anything about HTTP. Third, PowerShell is built for Windows by folks who really understand Windows. All that WMI, AD, LDAP, and XML that is a routine part of managing a Windows system is easily accessible from within PowerShell. And I've never seen an easier way to access COM objects from a scripting language. Finally, you have to try the object-based pipeline in PowerShell to fully appreciate what this means in terms of power and efficiency. Simply put, you don't have to spend all your time parsing text anymore. You think in objects and not regular expressions. Beautiful.
This leads me to an obvious topic: when will Office Communications Server offer PowerShell as a command-line scripting interface? Like many Microsoft enterprise products, OCS 2007 today offers WMI as the primary scripting interface for the product. Combined with WSH, you can get most things done via a command line. But it's no PowerShell. The roadmap we have for offering PowerShell consists of two phases. In the first phase, you can use PowerShell's native ability to work with WMI to access all of that functionality. We have a good proof-of-concept for this in the CD that accompanies the Microsoft Office Communications Server 2007 Resource Kit. Longer term, we are going to offer a native PowerShell interface similar to what is available with Exchange 2007. To do this right takes time. We want to provide an object model and corresponding PowerShell cmdlets that maps well to the product and provides an interface that will be useful for years to come. This means rethinking our entire WMI interface as it stands today and coming up with something better. As we make progress on what that new interface will look like, I will post more information and solicit your feedback.
The command line is cool again, especially on Windows, and I can't wait to show you what comes next...
