With PowerShell gaining more popularity and more adoption among developers/administrators, there is also increasing confusion between Command Prompt and PowerShell.
I will try my best to show case the differences between these two based on my experience.
Please read my other blogs on PowerShell to get some basic understanding of what it is and how it can change your life as an IT pro.
Lets gets started….
What is a shell?
Shell is a program that takes commands from the keyboard or mouse and passes on to operating system to perform requested actions. This could be as simple as opening a text file, navigating through your C or D drive, opening your internet explorer etc.
For instance look at the following examples and see why they qualify as Shell.
1. Windows Explorer ( is a shell ): It is one of the most commonly used shell with a GUI (Graphical User Interface).
This qualifies to be a Shell because, all it does is it takes input for your keyboard or mouse and helps you navigate through your files and folders.
2. Command prompt ( is a shell ): DOES NOT have a GUI works only with predefined commands like dir, mkdir, taskkill etc. which takes only text as input.
3. Windows PowerShell (is a shell): DOES NOT have a GUI works with predefined command-lets like Get-Process, Get-Help etc which takes objects as input and not just text.
Difference 1: Commands (PowerShell can execute all the commands that Command Prompt and beyond.)
Following images shows how ‘dir’ commands works on both Command Prompt and PowerShell. Do you see any difference? Not much, correct?
Please see below image executing a command-let ‘Get-ChildItem’ to list the same files with in the same Images folder. If you observe the previous example, ‘PowerShell’ was running ‘Dir’ command but behind the scenes it is executing ‘Get-ChildItem’ command-let. PowerShell ships with Command-lets only, some these command-lets execute on behalf of the DOS commands.
The following table contains a selection of the cmdlets that ship with PowerShell, noting similar commands in other well-known command-line interpreters. Many of these similar commands come out-of-the-box defined as aliases within PowerShell, making it easy for people familiar with other common shells to start working.
If you would like to know the total count of all the available command-lets available try to run the following command – @(Get-Command).Count.
The count varies from version to version of the Powershell, the following is for version 3.
Check your version by running $PSVersionTable.PSVersion command.
Difference 2: Generation Gap (Automation and Security)
Command prompt was born in early 1980s, it was doing well during its infancy and childhood , but when it reached its adult hood around 2005, it was facing some harsh challenges: Automation and Security.
It is very hard to find instances where you do not require to automate. All the things that you do on a daily basis can be automated such as creating an IIS site, clean up logs, back up databases and the list goes on…
Let see the following scenario where automation helps tremendously.
Imagine that your website is hosting ‘The Super Bowl’ or ‘The American Idol’ finale, can you fathom the amount of traffic you can expect for these events? Also think about the very next day or as a matter of fact, the very next hour once these events are done? There is very high probability or almost guaranteed that you will drop to 5% of your traffic that you had while these events are streaming live.
Do you believe it makes sense to purchase hundreds of servers just for a day or few hours and not use them for the rest of the year? How about any other events that can draw huge audiences but not as much as Super Bowl? You will be under utilizing your hardware then.
So ideally you need to scale-out or scale-down when ever appropriate. This scenario can be applied even for a day, for instance, if your’s is a stock brokerage firm and is very typical that you might have heavy traffic from 9:00 to 4:00 pm only, so does it mean that you can shut down few of your servers after 4:00 pm? Absolutely!!
It would be close to impossible to achieve something at this scale and time with out automation. Command prompt cannot achieve this with the limited commands it has and as a matter of fact it wasn’t designed or built for these use cases. One the flip side, Powershell is designed and well baked for automation.
Security is a broad topic and I am not going to deep dive, but this section will help you get some sense of what kind of security challenges that PowerShell solves.
Bad guys running .bat or .ps1 files:
For example, if you are running a .bat file (batch file: series of commands) it is all or nothing proposition, for instance, if a bad guy somehow gets access to your server, he can execute all the batch files he wished for.
With PowerShell you can set execution policy to run only digitally signed scripts, to go even further, you can even restrict the server not to run the PowerShell at all.
Impersonation or running in a different security context:
It is very easy to impersonate user with PowerShell it has built in cmd-lets to support it. It is possible with CMD prompt as well but not very straight forward.
Remote Command Execution:
Typically if you have to run batch files, you need to have these running on the server. With PowerShell it is designed to execute command remotely with out even copying the PowerShell script to the server that it is supposed to run. How this works? PowerShell is built on .NET and uses cmd-lets to accomplish tasks. As long as the server has the cmd-lets on the server, you should be able to run any command from any where. You can accomplish the same with Command Prompt, of-course not as elegant solution as with PowerShell.
Restricted permissions on the server itself:
When using Command prompt your options are limited. Even common administrative tasks might be tough or not even feasible to accomplish, for instance, modifying Registry and other administrative functions. With PowerShell ships with cmd-lets that make these administrative tasks absolutely pain free.
Difference 3: Adoption and Support
PowerShell is part of the CEC (Common Engineering Criteria) since 2009, which means that all the products shipped since then have to support PowerShell. All Microsoft products must ship with cmd-lets that help with administrative and maintenance tasks. Microsoft Exchange team is one of the early adopters and the product can be completely administered via PowerShell.
All such products from Microsoft stack, ship with these cmd-lets going forward. It is very unlikely that the will be any changes or improvements with command prompt to support these products. Even all the third party tools that are build on Mircosoft tools and software will provide support for PowerShell and not Command Prompt.
All data and information provided on this blog is for informational purposes only makes no representations as to accuracy, completeness, recentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.