I read somewhere that the first 4 days of using PowerShell is the toughest. Once you get over this hurdle, and try and go back to using another language you kinda resent it. Well I have been using PS for about 2 weeks now, and I have to agree. I used to be quite a previlent VBScript writer, but not any longer.
Once you can get over the hurdle of trying to work out “how” to do what you want to do in PS, the actual code is blindingly easy. Now I generally don’t do anything too involved (read:complex). Remember I’m looking at this puzzle from an admin/automation slant.
I have to say though that from this non-programmer perspective I have had the most issues trying to work out the “how”. Now that probably sounds pretty obvious, but let me clarify. When something is new to you, you can stumble into frustration quite easily when you learn a technique, and then go to apply it again in a similiar situation only to find it doesn’t work. Now there is probably a really good programtic reason behind this, but from the “new guy” perspective it is really annoying.
Now this post isn’t a flame thread, or “what I hate about PowerShell” because if I’m truthful I think it’s bloody great, and when I’ve worked something out I’m really stoked with how easy it is to do quite complex stuff. That being said below are the things that frustrate me most about PowerShell from my two week old perspective:
[1] A single element array no longer behaves like an array:
I used to have a habit of enumerating array using:
for i = 1 to ubound(MyArray)
To be fair this isn’t probably the best way to process arrays, but you know, each to their own and all that. Besides people are creatures of habit ;)
I found pretty quickly that this kinda sucks in PS. If you have an array with a single element it’s pretty much just treated as a string. So far I’ve found this kind of behaviour keeps cropping up.
Trying to create the first child element, in an XML document, for example isn’t treated as System.Xml.XmlDocument, but instead reverts to System.String. I think this is somehow pointing to the #text part of the element.I’m not sure if this is a bug or not? I noticed Adrian Milliner identify this in the comments on this on the MS PS Blog here and kindly mentioned the fix!
[2] PSBase method/class:
I guess this is where the non-programmer in me wonders just what exactly is going on there? I have to admit since implementing MOW’s community Tab Completion cmdlet I seem to be able to work my way through psbase implementations a bit better. Still it does primarily appear to obsfucate the whole thing, but maybe I’ll see the light further down the road.
There’s a good explanation of it here I’ve stumbled across psbase while doing ADSI scripting with PS, so I’ll highlight it during a post where it pops up.
[3] Microsoft Script Center
I’m not going to harp on about this as I have raised it in a previous post. Suffice to say most newcomers will look there for assistance and currently it’s just not a help. The PowerShell Team blog however is saving the day and those guys put up some excellent stuff that does help!
[4] Documentation
My issue here is accuracy. I could be alone in this so take this observation with a pinch of salt. I seem to keep finding discrepencies with the MS documentation for PowerShell. Now this is occuring in severalplaces. I downloaded the PowerShell Documentation Pack in case it had updated since RTM.
In the Working with Software Installations section of the User Guide I find that the syntax for installing MSI applications just doesn’t work!
The in-shell help is really really great. As a Linux user (Debian and Ubuntu) I find the Man-like approach to be a good idea. I tend to develop my scripts in-shell and then cut-and-paste them when they are working (more on this in another post).
Now the get-history invoke-history cmdlets are very useful, but I can’t seem to get some of the functionality to work correctly? In Example 4 of the detailed get-help out for Invoke-history is the following line:
C:\PS>invoke-history (16..24), 27
Whenever I try this I get this error:
PoSh> ghy
Id CommandLine
— ———–
1 cd ~
2 dir
3 [xml]$root = gc D:\coding\ps\th-ad.xml
4 $root.Post.ad
5 $root.Post.ad.OrgUnit
6 $root.CreateElement(“test”)
7 $ou = $root.CreateElement(“test”)
8 $ou.set_InnerText(“blah”)
9 $root | gm | more
10 get-help get-history
11 get-help get-history -detailed | more
12 get-help *-history
13 get-help invoke-history -detailed | more
PoSh> ihy (3..5)
Invoke-History : A parameter cannot be found that matches parameter name ‘System.Object[]
At line:1 char:4
+ ihy <<<< (3..5)
[5] No PowerShell availablity in WinPE
Not exactly a fait comment considering PS sits ontop of .NET and of course there is no .NET for PE. From an Admin perspective though this really does bite. You go through the effort of buying into the new technology. You get used to how cool, and easy it is to do stuff, and then you find that you can’t use it in one of the most useful scenarious.
Now this will in all likelihood stirr the big debate on WinPE anyway. I’ve always liked to boot into PE and have an HTA interface available to navigate through my build/recovery situations. Currently though I’m forced to use VBscript and C++. I want to move forwards it really should be PS and C#! ;)
I would like to caveat this post. I am a bif advocate of PowerShell. I’m trying to raise awareness within my organisation of what it can achieve, and I have found that the “Pro’s” massively outweigh the “Con’s”.
This post was just to highlight my issues. What have you’re issues been? Does the above work, and I’ve just not RTFM’ed, or have these just slipped through the cracks somewhere?
