Sunday, January 10, 2010
Sunday, January 3, 2010
I love Powershell I have written thousands of lines of code in it. I have used most of the great new features that were introduced into v2.0 but I have came across I couple of things that just annoy me. The first is that powershell provides lots of built in or automatic variables one of those new to v2.0 is the PsScriptRoot variable. You would think that with this name it would give you the Root of the Script that is running….Well sort of it only works in psm1 or module file. Why is it not $PsModuleRoot then. Finding the root of the script executing is a common action and it was nice to include this variable but why not for any executing powershell so I am left to keep using $MyInvocation.$MyCommand.Path for this purpose. The second little irritant is the fact that if you define params that are of type switch or bool and their value is set to $false (even if you explicitly set their default value) they do not appear in the $PsBounParameters collection. This suck in the case that you want to use that collection as an object initializer i.e. ( New-Object SomeObject –Property $PsBoundParameters ). In this case the bools on the object don't get set to false which is not really an issue unless the Object is PSObject and you are creating the Property Name/Values on the Object then the name and values don't even get created on your PSObject. Not Sure why the decided not to have the values appear in the $PsBoundParameters collection but makes code messier by having to define the complete hashtable with names and values of the switch or bool that is being used to initialize the Object. That said Powershell rocks and these can be worked around just seems like odd design choices to me.
This one liner will return the the module info in a easy to consume format. The info includes the full path to the module that the function is defined in. Good Time and Get-Command!!!
Get-Command -CommandType Function -Name Control-FPService | Select-Object -ExpandProperty Module | Format-List