Tue 22 May 2007
Actually, you could also say, it is an introduction into Windows Powershell from Microsoft. When I skimmed over the document, I came once again to the conclusion that Powershell is not really a shell, but just another scripting language.
This is at least true if you take the original meaning of the term “shell” which is just a user interface. Of course, you can also use Powershell on the command prompt. However, I doubt that many Windows sysops will really do this. Consider this example from the book which lists processes by its name and CPU time:
get-process | ForEach-Object { write-host $_.ProcessName $_.CPU}
Who really wants to type such longwinded commands? Yeah, you could also just use “get-process” to get a (different kind of) list of processes. But why not just use task manager for this? The point is, you usually need such a formatted list of processes only if you want to use it as input for another command. And that’s what I call scripting and not working on the command shell. Therefore, a better name for Powershell would have been “Powerscript” in my view.
I think that Windows doesn’t really need a powerful command shell because it has very powerful GUI tools. This is the main difference to Linux. However, there are some tasks you can’t even do with a powerful GUI. But then they are usually so complicated that a longwinded command won’t be of help either. That’s were scripts come in.
On my blog someone asked why Sever Core doesn’t support Powershell. The official answer to this question is that Powershell needs .Net which is not supported by Server Core. Another reason is that Server Core wouldn’t probably benefit much from Powershell because it is a scripting language and not a command shell.
Leave a Comment | 
Subscribe RSS
| 
Newsletter
|
Loading ...
[...] has a blog entry HERE where he opines: Actually, you could also say, it is an introduction into Windows Powershell from [...]
http://blogs.msdn.com/powershell/archive/2007/05/23/shell-or-scripting-language-it-s-shimmer.aspx
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
I politely disagree, on the shell side, its as much of a shell as cmd.exe is.. cmd.exe has alot of native management executables, while powershell has a bunch of generic (script enviroment sort of cmdlets) as well as a few management level cmdlets, (but thankfully it can call legacy executables as well), for admins, its all about use.. When a particular product provides action orienated cmdlets, then you’ll see the use for ad-hoc administration, an example of this is for exchange. I think the lack you are seeing, is a lack of targeted cmdlets in the powershell ecosystem for the administrative tasks that are important to you, and that is definately true at this point in the game.
With respect, I couldn’t disagree more! I don’t think “ps” is long-winded and it’s the same as get-process. The whole point was to make cmdlet names obvious (e.g., read the name, know the purpose), and then use aliases to make them pithy.
And no, Get-Process does not return a formatted list. It returns a set of Process objects, which you can then do stuff with - without scripting. The formatted list only results when the shell has been told nothing else to do. For example:
ps | sort handles -desc | select -first 10
Gives me the top ten processes by handles, something that could certainly be convenient for an administrator to look up now and again. Without creating a script file. Or:
ps | where { -not $_.Responding } | kill
Which would kill nonresponsive processes - again, certainly useful, and not a script.
The “core” of PowerShell was intended to contain minimal, basic functionality - it’s as Microsoft builds products like Exchange and System Center, which add 100% of their administrative capability to the shell, that the shell’s capabilities extend.
I think your skim of that intro content has probably sold PowerShell short.
Your comment about Windows not needing a shell because it has a GUI is one I’ll also debate. Perhaps some administrators can get by with clicking buttons all day long; in a large company (at least - there are other situations, too) that’s not acceptable. I need to be able to create dozens of users, move hundreds of mailboxes, and reboot dozens of machines, all at once and perhaps without writing a script. A GUI does not permit me to do this, a shell does. Unix and Linux administrators also have rich graphical environments to work in if they choose - the fact that they choose to work from a text shell is instructional: It’s because doing so is more efficient. A skilled PowerShell user can accomplish tasks much more quickly and precisely and consistently than a GUI user could - the key, of course, being “skilled” - you do obviously need to learn what you’re doing.
Certainly the GUI will continue to exist for less-experienced and less-skilled administrators, but the difference between “the men and the boys” (if you’ll forgive a gender expression) will be skills like PowerShell - not a piece of paper that says MCSE!
Trackback http://blog.sapien.com/current/2007/5/23/do-you-get-it.html [...]has a lot to say about his first thoughts about Windows PowerShell. Unfortunately, I think he may[...]
> I think the lack you are seeing, is a lack of targeted cmdlets in the powershell ecosystem for the administrative tasks that are important to you, and that is definately true at this point in the game.
I agree 100%. PowerShell provides a range of semantics from high level task oriented cmdlets to low level .NET object access. It will take a while to get Cmdlet coverage for everything. That said, every couple of months brings a new product supporting Cmdlets and a large wave of community developed Cmdlets/high level functions. You should definately download and use a few things:
1) the PowerShell Community Extensions ( http://www.codeplex.com/PowerShellCX )
2) MOW’s tab completion ( http://blogs.msdn.com/powershell/archive/2006/04/26/584551.aspx )
3) Karl Prosser’s PowerShell analyzer ( http://www.powershellanalyzer.com/ ). Ok - The way to think about that is that is resides in the middle ground between a SHELL and and IDE. It’s awesome.
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
Karl, I agree that admins will use PowerShell more often when products come with action-oriented cmdlets. However, I wouldn’t use PowerShell Exchange cmdlets on the shell. It is just too dangerous. A little typo can destroy a lot. Better write a script, try it in a test environment, and then run it on your productive system. And I would always prefer the Exchange GUI if I can perform the task there. It is faster and less prone to error.
“I think that Windows doesn’t really need a powerful command shell because it has very powerful GUI tools.”
Ouch! My wrist hurts and my fingers are turning numb just thinking about that statement.
For some functionality, a GUI cannot substitute for a shell (or command-line, whatever).
Example:
I want to see all the errors for today in the Eventlogs of 30 servers but only if they don’t involve printing and printers. On some I want to include SQL Server errors and on others I don’t (would filter them out). I need to see this at least twice per day.
Hmm… GUI or shell? Hmm….
Michael.. as for the risk.. one word -whatif
-whatif is great feature designed in powershell that lets you see what would have happened if you run the command. being able to back out of an action, or forsee what would happen isn’t very common in GUi application, sure its there in office applications, but added with alot of effort, and typically Administrative GUI only has the bare minimum to get the job done, there are many places , either at GUI or at the console when i have thought “ok, i think pressing this button - or running this command” will do what i want, but if it doesn’t , we’ll i’ll be looking for a new job - With powershell -whatif is my friend. Going forward it will be interesting to see how various products support -whatif
-Karl
michael, just another curious question. I’m trying to work out whether your issue with GUI versus Powershell, or GUI versus commandline period. Do you take value in the various administrative console applications from Net through the myriad of active directory ones etc? Do you ever use those, or soley depend on the GUI?
[...] http://4sysops.com/archives/free-windows-powershell-book-or-why-powerscript-would-have-been-a-better... [...]
First of all, I want to thank you all for your contributions here. I really didn’t know that my harmless comment would provoke so many emotions. I can’t reply to all arguments here. But as far I can see there is one main claim: “There are many things you can’t do with a GUI, so I use a CLI�. This assertion is certainly true.
However, I think CLI supporters often overestimate this argument. As far I can see all the examples mentioned here can also be done with GUI tools. Take G. D. Milner’s eventlog task. There are so many powerful eventlog tools out there just made for this. I discussed Eventmeister some time ago. And I think you could even do it with the new Event Viewer of Vista and Windows Server 2008.
It certainly happens often that we have tasks which can’t be done with a GUI. For example, we’ve about 40,000 users in our Active Directory. Of course, we didn’t use a GUI to get them in. But we certainly didn’t do it using a CLI, either. I had to write a C# program for this. As far I can remember, it never happened in my entire Windows career that I had to use a CLI to perform a task I wasn’t able to do with a GUI. In those cases, I always needed a script. I’ve serious doubts that PowerShell will change anything here.
However, based on the reactions here and on other blogs discussing this issue now, I plan to give PowerShell a chance as a shell. Since we will use it anyway as a scripting language in the future, I probably won’t lose too much time with this.
Karl, every now and then, I am working on the command line, but usually only with simple query tools like nslookup or ipconfig. Working on the command prompt is a bit like programming. To start self-progammed tools that perform changes is too dangerous without testing them first, in my view. I would never run a command that manipulates multiple Active Directory objects on a shell.
[...] seems to have been done without the help of a proof-reader. Don takes issue with something Michael at 4Sysops.com said: the key bit for me [...]