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.

-Karl

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….

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

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!

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