[ad]
For this article you should thank Patrick Ogenstad and his comment on my post , because I did not know about PowerShell until he mentioned about it… so a white point for him =)
The parts that will follow are snippets from the Getting Started document that comes with it…
Abstract
Windows PowerShell™ is a new Windows command-line shell designed especially for system administrators. The shell includes an interactive prompt and a scripting environment that can be used independently or in combination.
Introducing Windows PowerShell
Most shells, including Cmd.exe and the SH, KSH, CSH, and BASH Unix shells, operate by executing a command or utility in a new process, and presenting the results to the user as text. Over the years, many text processing utilities, such as sed, AWK, and PERL, have evolved to support this interaction.
These shells also have commands that are built into the shell and run in the shell process, such as the typeset command in KSH and the dir command in Cmd.exe. In most shells, because there are few built-in commands.many utilities have been created.
Windows PowerShell is very different.
- Windows PowerShell does not process text. Instead, it processes objects based on the .NET platform.
- Windows PowerShell comes with a large set of built-in commands with a consistent interface.
- All shell commands use the same command parser, instead of different parsers for each tool. This makes it much easier to learn how to use each command.
Best of all, you don’t have to give up the tools that you have become accustomed to using. You can still use the traditional Windows tools, such as Net, SC, and Reg.exe in Windows PowerShell.
Windows PowerShell Cmdlets
A cmdlet (pronounced “command-let”) is a single-feature command that manipulates objects in Windows PowerShell. You can recognize cmdlets by their name format — a verb and noun separated by a dash (-), such as Get-Help, Get-Process, and Start-Service.
In traditional shells, the commands are executable programs that range from the very simple (such as attrib.exe) to the very complex (such as netsh.exe).
In Windows PowerShell, most cmdlets are very simple, and they are designed to be used in combination with other cmdlets. For example, the “get” cmdlets only retrieve data, the “set” cmdlets only establish or change data, the “format” cmdlets only format data, and the “out” cmdlets only direct the output to a specified destination.
Each cmdlet has a help file that you can access by typing:
get-help -detailed
The detailed view of the cmdlet help file includes a description of the cmdlet, the command syntax, descriptions of the parameters, and example that demonstrate use of the cmdlet.
…and more
Besides the above mentioned things, powerShell also includes: a new scripting language (not the lame-ass batch), processes objects, object pipelines, interaction, etc. If you are interested take a look at microsoft.com/powershell
Once again thanks to Patrick….
SN says
cool
backbone says
I know… It’s to awesome to have words to describe it =)
Bogwitch says
Wot no Win2K support?
backbone says
nope… microsoft never cared about backwards compatibility… X(
anyway powershell was though for windows 2k8
freyk says
I’ve compared powershell with cygwin.
And i can now say that cygwin is more powerfull
Bogwitch says
Thanks freyk, I would have stuck with cygwin anyway due to the lack of 2k support, but that saves me investigating it for 2k3 up!
backbone says
freyk can you write a paper on your comparison? I’ll post it ;)
lrbell says
I think Powershell is better in a homogenous environment. I have written KSH BASH etc.. for 8 years, and LOVE IT, but actually having OBJECTS to pass around in Powershell is the HUGE difference maker.
It all has to do with what you want to do.
If the environment is Windows centric, then the Powershell is easily superior.
If it is heterogeneous, then I would have to agree that Cygwin/Perl etc… ties the pieces together. Python has topped the list for me of late.
It is the age old argument. It just depends on the task of the day, and the direction of the group.
On that same note. Powershell is packaged with Exchange 2007 and also works with SQL 2005 SMO (SQL Management Objects).
It also plays nicely with Sharepoint, Active Directory, and will be bundled with Server 2008.
Also, I have found that rudimentary automation in Windows with Powershell can effectively cut out 80% lines of code.
What takes me 200 lines in VB or Java, takes 20 lines in Powershell
(It took MSFT until 2006 to get it going, vs. 30 yrs ago in UNIX LOL!!).
freyk, please let me know what you found to be far superior in function, as I too am interested in knowing.
BTW, Cross platform is a no brain-er.
L
backbone says
very interesting thing you point Irbell… i think that is very good to have ppl who are accomodated with powerShell to tell us some informative tips about it…. keep up the good commenting… ;)
backbone says
I wrote a comparison between bash and powershell for the ones who really want to see them compared in an non-subjective way =)
http://backbone.lx.ro
Joaquin Menchaca says
Considering only the Windows platform, you have a command shell that only works on certain Windows (no w2k), and doesn’t have raw ability to access important parts of OS needed for security and system administration (ACLs on pipes, services, drivers, etc.). So to get the job done, one will used Windows command console tools from 3rd parties, e.g. system internals group at MS, do stuff in C++, or well, just use Perl which has wrappers to a lot of these.
In contrast to all the platforms, Powershell looks extremely resource intensive, and limited or cumbersome to program in certain areas. For example, short-circuit operations:
command1 && command2 # do command2 if command1 succeedsAnd still, just piping objects is limited when you just want to get at the text:
command | awk '{ do stuff }' # easy
command | perl -a -e 'do stuff using $_ per line' # easy too
command | write "strings using $_" # fails in power shell
command | } # works, ugly
Notes: Web Site Mangling my Code, cannot do ampersand squiggly “process” squiggly combination.
lrbell says
I am right there with you on a lack of backward compatibility, but upgrade and commence!
Now this is just not accurate Joaquin;
“And still, just piping objects is limited when you just want to get at the text”
The absolute sweetest thing about PS is that beneath teh covers you are pass OBJECTS around.
command | foreach {$_.getSomthing}works like a charm.
Piping objects, not text.
so, get-Process | foreach{$_.ID} will spit out all the PIDs for the procs running, ala “ps -ealf” in my beloved *NIX.
Anything that is not a cmdlet can be cast to the .NET object of your choosing, and hence has the properties of said object.
You can pipe a cmdlet to Get-Member and see the plethora of methods and properties associated with the object.
For example;
Get-Childitem | Get-Memberwill return all methods and props associated with a file or directory object.I do not mind the opinions, but be sure facts are straight to be fair.
HTH
L
Sir Henry says
I have found powershell to be vital when working in a windows environment, while being a linux user first. There is no better feeling that to have all the same tools and commands at your disposal when you absolutely have to use windows.