 |
| cmd.exe |
 |
| Powershell |
Traditional command lines such as windows cmd.exe and linux bash just execute programs that one specifies (like ls, ping, ipconfig, dir etc) and display the output on the screen. These programs figure out the executable to execute based on a variable they store(such as $PATH). These variables store a list of directories in which to search for the desired executable. For example, if the user types "ping", cmd.exe will search the local filesystem for an executable called "ping.exe", execute ping.exe, and display the output to the console. Once ping.exe is done executing, control returns back to cmd.exe, which will wait for another command.
Powershell is different. Unlike traditional command lines which are essentially text brokers (they just get the text from other programs and display them for you), Powershell has the notion of "objects". The powershell commands are of the syntax Verb-Noun, for example one might see "Get-Mailbox". Objects returned from these commands are actually .NET objects, and all the text that is displayed is the result of printing the data member fields of those objects. For example, If one wanted to print the Mailboxes an Exchange Server Hosts, one would type "Get-Mailbox". What the user would see on the screen is the result of iterating through a list of objects and printing the requested data for each object. In this respect, one can think of Powershell as an "Object broker" rather than the older "Text broker" model.
Another major difference between Powershell and the older command lines is the way in which new commands are made available in the console's runspace. In the older model, the user could just drop an executable into a directory monitored by the shell, type the name of the executable, and it will execute. With Powershell, all the commands available in the current runspace are commands that have been loaded from a pre-loaded .NET assembly. These assemblies come in the form of .NET assembly dlls. First the dlls have to be registered with powershell. During registration, Powershell modifies its list (which is stored in the registry) of known assemblies. Once the dll is registered, Powershell must load the assembly. In the loading stage, powershell actually reads the contents of the dll and adds the commands defined in the dll to its list of known commands. Once loaded, a user can type "Get-Ma", hit the tab button, and have powershell autocomplete guess "Get-Mailbox" if the correct assemblies are loaded.
Another cool innovation from Microsoft is remote Powershell. It is very similar to ssh on Linux, but it runs on Windows. Remote Powershell was a very needed feature in the windows environment, and could not have come soon enough.
Powershell is available for older versions of windows such as XP, Vista and Server 2008, but comes built into newer versions of Windows such as Windows 7 and Server 2008 R2. Many of Microsoft's new technologies, such as new versions of Exchange use powershell, so it really pays for System Admins to become familiar with this technology.
References:
http://www.amazon.com/Professional-Windows-PowerShell-Programming-Providers/dp/0470173939
What are the advantages of Powershell? It's possible to do tab-completion with text-based shells. And why not use cygwin instead?
ReplyDeletehey t00lb0x. Microsoft is moving all their technologies to Powershell. The management for Exchange as well as other software is being moved to Powershell. For example, in the GUI Exchange Management Console, the things i click, and my actions are converted into powershel commands and executed. its better than the traditional command line because it is object based, and thus provides more flexaibility. i can have 2 commandlets i write, where one produces object X, and the other consumes object X. then, when i pipe the output of one command to the other, i would just do:
ReplyDeletecommand1 | command2
this makes commandlet writing easier.
Some things I like in PowerShell and find better than Cygwin (and typical Unix/Linux shells):
ReplyDelete* PowerShell is Object-oriented. E.g. the result of a command is an object with properties rather than text, you pipe those results to another command and then access its properties. No need to cut, awk, sed, etc. in the pipeline between commands.
* Easy built-in access to the .NET class libraries, COM objects and WMI. The amount of functionality that works right away as if it were "pre-installed" is simply mind-blowing. For example, if I want to provide voice prompts, in Cygwin I would normally need to install or write a command-line application that invokes a speech synthesizer and then call it. In PowerShell I just invoke the speech synthesis API. Ok, voice synthesis may be primarily a "showoff" example but you have all kinds of functionality: how about arbitrary-precision math, all the collection classes (stacks, queues, hash tables, dictionaries, linked lists), etc? Of course you also have access to all the APIs for system configuration, networking, i/o, database access, etc (but that functionality may be more common in cygwin/Unix/Linux, it is less of an advantage in comparison). Just take a look at http://msdn.microsoft.com/en-us/library/aa388745(v=vs.85).aspx to get a feel for the breadth of APIs
* The job and remoting infrastructure in Powershell is very powerful. E.g., if you want to run a command remotely on 100 machines but only 10 at a time (starting jobs on new machines as the launched jobs report completion) that would normally require some effort in cygwin/Unix/Linux but it is one simple line in PowerShell (see http://www.everythingpowershell.com/2010/04/what-is-throttling-when-using-powershell-remoting.html)
Don't get me wrong, I like cygwin, it includes many more things besides the shells ;) but, in my opinion, if you're working with Windows machines and you are the kind of person who can be comfortable and productive at the command line, you're doing yourself a disservice if you're not giving Powershell a serious try