Friday, 30 January 2009

Preventing boredom with numbers (and Powershell)

During one of those lapses in motivation this afternoon at work I had a go at putting together a Powershell script to list a sequence of Fibonacci numbers (in true geek style, did I do it because I needed to? No. Did I do it because I wanted to see if I could? Yes). Disappointingly I got it done pretty swiftly which meant that I had to get back to doing some real work, but being able to make it a one-liner was quite satisfying:

$1=0;$2=1;$3=$1+$2;do{$3;$1=$2;$2=$3;$3=$1+$2} while ($3 -lt 10000000)

The code above uses 0 & 1 as the starting numbers (just change the values assigned to $1 and $2 to use others) and keeps going until the result is greater than 10000000. If I get bored next week (ha, ha! as if....) I might use the speech capability I mentioned here to get the script to read out the numbers for me, interspersed with profanities....

Thursday, 22 January 2009

Clock-a-doodle-do!

Added a clock to the sidebar from ClockLink. Useful if you find that it's too much effort to look at the watch on your wrist....

Tuesday, 20 January 2009

Windows7

Like countless others I've downloaded the beta of Windows 7. Being a TechNet subscriber I was able to download copy before the general public, and more importantly before Microsoft's infrastructure melted and required an upgrade. If you haven't had a chance to take a look at the new OS and want a quick tour of some of the new features, Jamie Burgess of Microsoft has created a video manual covering the new features like this one on the new task tray:
You can find the rest of them here on Jamie's blog.

Thursday, 15 January 2009

Dirty code

Everyday I like to try and learn something new. Today, courtesy of The Scripting Guys it's been to add speech output to VBS and Powershell scripts. Other than giving some of my scripts a potty-mouth not really much use. Very funny though, well for at least five minutes anyway...

Wednesday, 14 January 2009

Do more (or the same) with less...

One of the best the best things about Powershell (and there are many) is that it allows lazy IT Pro’s like myself to be just that: lazy, or in my case even lazier than normal. Someone on my team at work today asked me how to query an environment variable using VBS. Being as inherently lazy as I am my first answer was “I can tell you how to do it in Powershell” because I knew it was a one-liner, whereas VBS would require a bit more typing.
Say you needed to get the value associated with the environment variable PROCESSOR_IDENTIFIER. To achieve this in VBS you’d do something like…

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colEnvVar = objWMIService.ExecQuery _
("Select * from Win32_Environment where Name = 'PROCESSOR_IDENTIFIER'")

For Each objEnvVar in colEnvVar
wscript.Echo objEnvVar.Name & ": " & objEnvVar.VariableValue
Next

Granted it’s not the longest piece of code ever typed, but why wear your fingers out any quicker than you need to. To get the same information using Powershell all you need is…

get-childitem env:PROCESSOR_IDENTIFIER


get-childitem is usedto retrieve the items from the specified location which in this case is env: which is the Powershell environment provider, and PROCESSOR_IDENTIFIER specifies the relevant variable to report on. If you want to report on all variables, and type even less, try…

gci env:*


gci is the alias for get-childitem and the wildcard means all variables will be reported on.
So if you want to be able to start putting less effort into things, try Powershell.

Monday, 12 January 2009

The answer is out there...

I've been playing with Powershell for some time now, pretty much since it was still codenamed 'Monad' (I say 'playing' as the only PS scripts that I've put into production have been at home as all my scripting at work is still either VBscript of old-school .cmd). If you've done anything with Powershell you'll know how easy it is to get stuff done in considerably less code than would normally be required with VBS. At one of the sessions I attended at TechEd last year, Jeffrey Snover the architect behind Powershell said he'd seen examples of massive code reduction, the best behind 481 lines of VBS down to 1 line of Powershell. Hmm, so far rewriting some of my scripts from VBS to Powershell have only achieved about 50% code reduction but given my coding skills (!) that's pretty impressive. Still, it gives me a target to work to I suppose...

Anyway, I've been working on a PS script part of which was the need to compare two pretty big file listings and I'd reached a point where I was going to have to export the output and use some other method of comparing to identify the differences...until I checked out my RSS feeds this morning and there was my answer: compare-object. Trust me, at this point I probably felt as foolish as the acquaintance who once decided to swap carriages on the Alton Towers monorail at the last minute only to be left standing on the platform as I amongst others mocked him from the quickly departing train. Anyway...

$compare1 = (gci c:\path1 -recurse where {!$_.PsIsContainer})
$compare2 = (gci c:\path2 -recurse where {!$_.PsIsContainer})
compare-object $compare1 $ompare2


...got the desired result, so todays blog of the day (other than this one ha, ha!) is Dreaming In Powershell.