"Is PowerShell really a new shell, or is it a new scripting language?" Customers ask me this question quite a bit. I guess it really depends on your definition. If you reference Wikipedia for a definition of command shell (http://en.wikipedia.org/wiki/Shell_(computing) ), you'll get this:
"In computing, a shell is a piece of software that provides an interface for users. Typically, the term refers to an operating system shell which provides access to the services of a kernel."
So, by that definition, then you would probably have to say "yes", as PowerShell certainly can do this. However, that definition doesn't really cover all the bases for some users. Some users feel that a shell should allow very simple but very robust command line interface actions. In other words, they should be able to access anything in the system with a few basic keystrokes.
I will have to admit that until recently I've mostly used PowerShell for scripting only, and haven't really taken to using it as a shell. In order to test to see if PowerShell could really be used as an everyday shell, I decided to give PowerShell a one month test run as a shell first and scripting language second.
A Few Minor Issues:
As I began using PowerShell as my daily shell, I ran into a few minor issues due to syntax. For instance, in a CMD/DOS shell, the following works:
CD\
CD..
The problem is, this doesn't work in PowerShell, as CD is actually an alias to Set-Location. You now have to use:
CD \
CD ..
Not a huge issue, but having been using the former since the DOS 6.22 days, it takes a bit of retraining to get used to. You'll find many of the commands you used to use will have this type of limitation.
The other issue I ran into were in regards to switch usage. While most old DOS style commands will work (i.e. DIR /P) not all commands are represented.
What this really boils down to is that if you are very familiar with DOS type commands, not everything is going to work as you previously knew it. As PowerShell is a new shell, some commands may have to be relearned/adjusted to work properly.
Using Legacy Shell Scripts:
I also have a lot of old batch files/shell scripts that I have laying around. I still use most of them. What I did find with these is that the majority of them worked, however, some needed to be upgraded to deal with switch and parameter issues as discussed previously. You do have to start them in the same way you start PowerShelll scripts, by executing a backslash in front of them such as: .\runme.bat
One of the main issues I ran into is chaining separate .EXE files.
For instance, when I ran a script that executes an .EXE that extracts data from Active Directory to a CSV file for processing, I found that PowerShell did not wait for the EXE file to finish while the old CMD shell did. This can normally be handled by using the START /WAIT command in the standard Windows shell, but this will not work in PowerShell. Hence, I had to come up with the following function to do this:
Function DirExport {
$StartApp = new-object System.Diagnostics.ProcessStartInfo
$StartApp.FileName = "gwdirapp.exe"
$StartApp.Arguments = " /A user01"
$StartApp.WorkingDirectory = (get-location).Path
$GMEDirApp = [System.Diagnostics.Process]::Start($StartApp)
$GMEDirApp.WaitForExit()
}
Not as clean as I would have liked, but usable. By implementing this, you also have to upgrade the script from a .BAT or .CMD to a .PS1.
So, Shell or No Shell?:
Other than the issues above, I really encountered no major issues using PowerShell over the Windows DOS/CMD shell. I think the important thing to remember is that PowerShell is both shell and a scripting language. However, it's important to remember that if you're going to use it as a shell, then treat it as a NEW shell, and not just an upgrade of the existing DOS/CMD shell. Some commands and functions may have to be reworked to function properly.
Eric Gentry
Senior Consultant
Project Leadership Associates
