PowerShell vNext: AST.

What is that?

There is one addition in PowerShell vNext that I look really forward to. In v2 we have parser available. It makes work with PowerShell code easier. But PowerShell team haven’t stopped there. AST (Abstract Syntax Tree) is new concept (at least – to me) and it makes parsing code more interesting: instead of stream of tokens (which is still there with AST and is also more accurate than v2 precedents) we get tree of syntax: from Script to single Statement. Browsing thru that tree may be very hard at first. I tried to use view that seems natural for that kind of complex structures: Format-Custom. The problem that I went into was the fact, that each AST contains “Extent” and “Parent” property. And those properties keep whole code which makes Format-Custom lengthy and impractical. So my first step was to create .ps1xml files to make format and object themselves bit different. I hidden two properties I think are not very useful. You can still access them using psbase on each object – and that exactly the information you get if you try to access them directly. Next step I took was to create simple function that would wrap .NET call to System.Management.Automation.Language.Parser static methods (ParseInput, ParseFile) and make use of them more natural and PowerShell-ish. Then I packed it all in the module, so that I could paste it somewhere and let others use it and complain about things I did wrong (like using global scope to store tokens/ errors).

Read more…

Shell for Windows not Bash for Windows.

I love PowerShell. Literally it saved my behind several times, made my work on Windows 100s more fun than it was before it was shipped (or rather before I tried it and got familiar with all it’s concepts). My first meeting with scripting was bash, but it was long ago, so maybe I will miss some points in this article. But there are so many articles written by *nix experts that tried to jump in opposite direction and were disappointed, that I decided to write this thingy to maybe explain why (in my maybe not very humble opinion) that was the case.

Object in pipe.

All starts there, really. Even if folks understand concept of pipe that passes object all the way, they still try to filter, select and act on strings. It was something impossible for me to avoid in bash. I haven’t done it really ‘hardcore’ way. Only grep, awk, sed, cut, find and xargs. So it was probably just scratching the surface of what *nix shells have to offer. But I’ve seen many times same patterns applied in PowerShell by people who just refused to go all the way and change from thinking-string to thinking-objects. And if there is no grep-substitute some people get lost and blame PowerShell for it. OK, you are probably right, you spent a lot of your time and effort to find out how to play with text parsing and would like to leverage this in Windows in the same way you did on your *nix box. But there are better ways to achieve this goal (I mention it at the end). Powershell is great for filtering, but you have to see objects, even if there is text. And use cmdlets *designed* for filtering. Where-Object is very powerful and can work both with string and with full objects. So no: “Out-String | Select-String” please…

Console is not PowerShell.

Another very common mistake I see is assuming that ‘blue box’ is Powershell. Full stop. I agree that ‘blue box’ is very limiting at times. It also has many ‘features’ that may drive people crazy. Like selecting text inside it, all that ‘Quick Edit’ modes, size that does not scale unless you tweak it using $host variable, limited number of fonts to select from… List goes on. Mine favourite ‘feature’ is Tab-killer (best option to get rid of everything after cursor is to press tab 😉 ). But there are at least 3 other hosts available for free (one out-of –the-box on Client machine and as optional feature on server). All do better job in my opinion. And there are some commercial alternatives that probably do even better than that. I personally use ISE, PoshConsole from time to time, and there is also PowerGui script editor, that can serve as console window too (greatly improved in version 2.4). If you don’t like powershell.exe – just stop using it. But don’t pretend to be powershell expert if all you did was launching this blue box and looking at features of host. Powershell is engine that maybe used in many hosts, including old and not very smart ones, like [system.console] 😉

Pain of growing too quickly.

Another thing I would like to point out. It’s unfair to compare something mature and improved over last 30 years with stuff that is still not full-featured yet. As Jeffrey Snover keeps saying all the time: Microsoft is digging itself out of the big hole, and it takes time. I would imagine it also forces PowerShell team to make some painful decisions: we won’t make this, this and that in this release. And now when PowerShell is a part of Windows as a whole the release cycle is tied to OS cycles. It forces us, PowerShell users, to wait longer for new improvements. Good part is that PowerShell team did a great job to make it possible (and pretty easy too) for community to extend functionality of PowerShell. Many requests I’ve seen from *nix folks were implemented long ago by creators of PowerShell Community Extensions (pscx) but still, some things that we (users) and team (trust me on this one) would like to see in PowerShell will take a while to complete. It does not mean that we can’t do it ourselves already (I hope to find out HOW during TechEd next week, there will be session that I simply can’t miss exactly about that) – it means that we can’t assume given functionality is available on every box, and of course it makes our life harder (WE need to check if given module is installed on box). But the fact that we can prepare some really wonderful extensions without asking Microsoft to do it makes it really great. But to have mature product – we need more time. I will wait, I’ve already see it’s worth it.

Different world, different shell, different mind set.

I’m windows admin for quite some time. Do you know how often do I need to parse text to solve tasks? My world is built of objects. Even text is build of objects. I need something that simplifies working with objects and makes it possible to automate object creation, usage and recording (as text, obviously, I can not read anything else unless it’s image). Folks from *nix part of the world come to windows and want to have something, that would improve their life inside it. They assume shell is only good if it’s built on text parsing, because they are used to that kind of shell scripting. Seen comments that ‘cp’ is obvious command (oh really…?). Sorry guys. You are obviously trying to convince world, that only because you spent time and learned by hard all commands and patterns from *nix shells, than Windows shell should follow same rules. I see reason why this assumption is made. When you see ‘ls’, ‘cat’, ‘cp’, ‘rm’ – you may start to think that this is just bash-clone on windows box. And it’s not the point: all those aliases are created only to allow shell users (both cmd and bash) to use some commands that we already have in memory. No way ‘cp’ is more obvious than Copy-Item. If I have no idea what Select-String does I can guess. Try guess what poo command would do? Or huhu command? And what about Get-Elevator? Show-Picture? We have many objects, our world is too complicated to study by hard all shortcuts that team producing some functionality thought were cool and easy to remember. That’s were PowerShell saves our back. We can do lucky guesses, we can Get-Command, Get-Help, we can push object all the way and Get-Member, make lucky guesses on that members too. And move on. Really, something that I would like to see everywhere.

Get-Kid | foreach { $_.Feed() } # done with breakfast 😉

Bash on Windows box.

Now last point. If you really want to use your bash skills when you manage Windows – you can. It’s there for quite some time, and it works fine (and I won’t argue if that is better option than Powershell – for sure it’s different). Don’t try to convince world that PowerShell has to be bash-clone. It shouldn’t be. If all you need is bash on windows – use it there. Never tried myself, but there are many folks who did Cygwin + bash and are more than happy with that couple. You may complain that it is not there by default. But why should it be? And wouldn’t part of *nix experts that spell MS as M$ complain, that Microsoft is ‘stealing’ again? I’ve seen such comments even for aliases in PowerShell. If they moved that far with something that was designed to make start in PowerShell a bit easier for people who are used to work in bash – how far would they go if Microsoft would decide to have both bash and PowerShell side by side as two alternatives? I will do easy guess: they would barf on M$, complain about it, and in the end – install cygwin + bash themselves, because there has to be something wrong with version shipped with Windows and updated using Windows Update, WSUS or SCCM. After all it’s M$, right? 😉