Automating the world one-liner at a time…
Ying Li has a cool PowerShell Script to list installed Software on a local computer HERE.
When I looked at it and thought to myself, I can do that with 1 line (if I cheat a little). Here it is:
PS> gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |Select DisplayName, DisplayVersion, Publisher, InstallDate, HelpLink, UninstallString |ogv
Here is what you get for that 1 line of code:
I cheated by using OGV (Out-GridView). Ying used Excel and the output is nicer. But when you only want to spend a single line… :-)
Experiment! Enjoy! Engage!
Jeffrey Snover [MSFT] Distinguished Engineer 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
Get-WmiObject Win32_Product | ogv
On x64 machines, if you want to do it with gp, you need "gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select DisplayName, DisplayVersion, Publisher, InstallDate, HelpLink, UninstallString |ogv"
As Doug points out there's an issue with 64 bit machines. What he has done is to show how to find the x86 installations from a 64 bit powershell. If you want to find installed software you'll probably want to find 32 and 64 bit programs, so you'd need to collect the data from two locations and aggregate it.
So, this doesn't actually work on 64 bit machines. Although it looks neat.
It would be sensible to check that you weren't running a 32 bit powershell on a 64 bit system as well.
Arrgh!! Bummer! Doesn't work in Windows 2008 R2 x64 Server Core :-)
-Nice try though (Saying it to myself) :-)
Out-GridView : To use the Out-GridView cmdlet, install the Windows PowerShell I
ntegrated Scripting Environment feature from Server Manager. (Could not load fi
le or assembly 'Microsoft.PowerShell.GraphicalHost, Version=22.214.171.124, Culture=ne
utral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system
cannot find the file specified.)
At line:1 char:229
Can you explain why there is so much focus on one-line commands? I don't see anything wrong with having a well-structured, multi-line script. It all depends on someone's goal. If I can accomplish my task using one line, great! If not, I don't want to feel guilty for writing a complex PowerShell script.
Ying's example of logging to Excel allows him to add his own formatting, and save the results to an Excel document, whereas the Out-GridView cmdlet does not.
I would caution you to avoid making people think that they should always be able to accomplish a task in one line of PowerShell code.
There is nothing wrong with multi-line scripts. Most functions will be accomplished that way. That said, one-liners are a good acid test to determine if we got the abstractions and the composition right. We want to produce a world where: you think, you type, you get.
Thanks for the response. I just sometimes get the feeling that people are being pushed to get things into one line, which as we've already discussed, isn't always the best option. If you're simply using one-liners as a test of your platform development, I can understand that.
The only other thing I'd mention is that, I think you've said in the past, that PowerShell is geared towards non-scripting admins. That's fine and all, but I often just wonder in my head, if PowerShell is overly simplifying platform automation. It's nice to have tasks be easy to accomplish, but if it comes at the cost of warping someone's perception of programming, it may not be worth it.
Maybe I'm expecting too much of PowerShell, and maybe I'm just talking too much, but I honestly like to think of PowerShell as a powerful, but simple, programming (albeit high-level) language, especially given the ties into .NET platform. I tend to think that admins who understand the basic building blocks of programming, like control flow, are much better off than those who are restricted to leveraging the PowerShell pipeline & built-in cmdlets. I use the cmdlets somewhat regularly myself, but my strongest positive perception of PowerShell is the fact that it's an easy language, and simultaneously provides powerful capabilities, by providing direct access to the .NET BCL.
Am I making any sense? :-\
ps. You guys have done great work on PowerShell. Please take my feedback as constructively as possible, as it's meant to be such.
With me, it was more like:
I sometimes got,
Repeat until I got
Felt bad when it wasn't "the powershell way"
I think it was just my lack of experience with shells and .NET. After having read about Monad in the Script Center's interview with Jeffrey Snover and Lee Holmes, I decided to just master a handful of cmdlets and to forget about trying to write scripts with the least amount of lines or trying to find "the right cmdlet" for a given task.
I don't know why I thought that a powershell script had to be written a certain way, but reading the scripts in the Scripting Games and questions in the Scripting Guys Forum, I don't think that I was the only one.
Thats cool, I will include it in my next version of my audit report as the current WMI class is not installed by default on 2003 (not sure about 2008).
I must agree with the comments above about one-liners being an unrealistic and pointless goal - it makes both error trapping and readability harder, and coveys a false notion that you've failed if you can't do it in one line.
As an aside, I have a question about the use of the GridView - how would this be used synchronously - i.e. for PS to block execution at that line until the user closes the grid? By default, it pops up asyncronously, and is torn down as soon as the current PS process terminates.
How would this be done remotely
Easy: Get-WmiObject -Class win32_product -Impersonation 3 -computername [your target pc]