jaybaz [MS] WebLog : PowerShell

Screenshot of Select-GraphicalFilteredObject.ps1 in action

jaybaz_MS — Wed, 12 Sep 2007 22:53:00 GMT

A picture would be helpful in understanding what this script does.

dir $pshome | Select-GraphicalFilteredObject.ps1 -title "Jay's blog is the best!"

gives this UI:

Powshell GUI for selecting objects in a pipeline ("Select-GraphiphicalFilteredObject.ps1")

jaybaz_MS — Wed, 12 Sep 2007 22:39:00 GMT

This is an enhanced version of a script from Lee Holmes' book Windows PowerShell Cookbook (O'Reilly). The original script takes a pipeline & presents a GUI that lets you select which elements to pass on to the next step in the pipeline. That's unchanged, but my enhanced script does a little more:

Added 'All' and 'None' buttons
A little space around the checked list box
Option to set the title to something domain-specific
Turn off CheckOnClick behavior because I think it's annoying but leave it as an option, if you like that sort of thing.

EDIT: Fix the attachment.

PowerShell polyglot

jaybaz_MS — Thu, 26 Apr 2007 20:20:00 GMT

Here's an example of a CMD script that is implemented in PowerShell.

@@:: This prolog allows a PowerShell script to be embedded in a .CMD file.

@@:: Any non-PowerShell content must be preceeded by "@@"

@@setlocal

@@set POWERSHELL_BAT_ARGS=%*

@@if defined POWERSHELL_BAT_ARGS set POWERSHELL_BAT_ARGS=%POWERSHELL_BAT_ARGS:"=\"%

@@PowerShell -Command Invoke-Expression $('$args=@(^&{$args} %POWERSHELL_BAT_ARGS%);'+[String]::Join(';',$((Get-Content '%~f0') -notmatch '^^@@'))) & goto :EOF

If you don't need to support quoted arguments, you can even make it a one-liner:

@PowerShell -Command Invoke-Expression $('$args=@(^&{$args} %*);'+[String]::Join(';',(Get-Content '%~f0') -notmatch '^^@PowerShell.*EOF$')) & goto :EOF

Controlling Virtual Server through Microsoft PowerShell

jaybaz_MS — Tue, 23 Jan 2007 00:26:00 GMT

In his post by the same name, Ben describe a series of steps required in order to manipulate Virtual Server from PowerShell.

I'm still a PowerShell novice, so I decided to use this problem as an opportunity to see if I could make things a little easier.

The reason it's hard is that you have to make a call to a native Win32 API, which is not accessible from PowerShell directly. Ben's solution includes a peice of C# code that makes this call via interop, and then you have to compile it & load the assembly before you can do any work. In my solution, my script does that work, as well.

Here's the code:

$csc = (join-path ($env:windir) Microsoft.NET\Framework\v2.0.50727\csc.exe) $code = [IO.Path]::GetTempFileName() + ".cs" echo @" using System; using System.Runtime.InteropServices; public class PowershellComSecurity { [DllImport("Ole32.dll", CharSet = CharSet.Auto)] public static extern int CoSetProxyBlanket(IntPtr p0, uint p1, uint p2, uint p3, uint p4, uint p5, IntPtr p6, uint p7); public static int EnableImpersonation(object objDCOM) { return CoSetProxyBlanket(Marshal.GetIDispatchForObject(objDCOM), 10, 0, 0, 0, 3, IntPtr.Zero, 0); } } "@ > $code $assembly = [IO.Path]::GetTempFileName() + ".dll" & $csc /nologo /target:library /out:$assembly $code [System.Reflection.Assembly]::LoadFrom($assembly) > $null function SetSecurity { [PowershellComSecurity]::EnableImpersonation($args[0]) } $vs = new-object -comObject "VirtualServer.Application" SetSecurity($vs) $vm = $vs.FindVirtualMachine("public") SetSecurity($vm) $guest = $vm.GuestOS SetSecurity($guest)
$guest

It could use a little tuning. If I was going to do this a lot, I'd put it all in to a new script.

export environment variables from CMD to PowerShell

jaybaz_MS — Thu, 18 Jan 2007 03:52:00 GMT

If you want to use PowerShell, but already have a CMD script that you want to keep, and that CMD script sets environment variables, you're in a pickle. Now I like pickles of all kinds, but Lee can help you get out of this one, with a script that exports the env. vars. back to the PS host.

It's all in his post on entitled Nothing solves everything – PowerShell and other technologies.

Microsoft PowerShell is awesome

jaybaz_MS — Sat, 13 Jan 2007 02:20:00 GMT

At work I've been playing with Windows PowerShell. I could try to describe it, but Wikipedia has already done a better job:

Windows PowerShell, previously Microsoft Shell or MSH (codenamed Monad) is an extensible command line interface (CLI) shell and scripting language product developed by Microsoft. The product is based on object-oriented programming and the Microsoft .NET framework.

Windows PowerShell 1.0 is available for download from the Microsoft web site.

It blows my mind how cool it is. Unfortunately it also, uhh, fries my brain because I don't know how to use it. I'm a cmd.exe expert. Seriously, I know way, way too much about writing CMD scripts, to the point where most people can't keep up. I don't want this knowledge, and I see that PowerShell may give me freedom from the burden of the knowledge.

My biggest annoyance is that it's not universally available. I want to be able to sit down at any machine and just start using PowerShell, not having to worry about installing it (and the .Net Framework) first. I want to be able to offer .PS1 scripts for anyone to use, without them having to jump through the same hoops.

Too bad it missed the Vista train. That means it'll be 10 years before it's everywhere. We'll get there.

Transition time

jaybaz_MS — Thu, 20 Oct 2005 18:26:00 GMT

We're at the point in the process for VS2005 where there is basically no work left for devs to do. (The product hasn't shipped yet, but devs are not busy.)

Before starting the next product cycle, there are a few things that we're doing differently. One of them is "transition time", a form of slack. The end of a product cycle is always a lot of hard work, with a lot of pressure. We strive for maximum efficiency, and a lot of other important things get pushed off. The slack time is a chance to restore balance.

The first part is 7 days of self-directed time. These are work days, but there is nothing scheduled. Different people are doing different things:

Talking to teams that are exploring long-lead ideas about new technology
experimenting with retrofitting our legacy code for unit tests
cleaning & rearranging their office
building applications with VS2005
reading

I have been reading the new XP book (Extreme Programming Explained: Embrace Change, Second Edition, by Kent Beck). Combined with the first edition, it's very good stuff.

I have moved in to a new, larger office. I'll have to get some pictures to share & gloat.

my side project

I have been working on my side project, which is written in C#. It's not something that would be useful outside of Microsoft, so I won't go in to details about what it does.

I always wrote it in C# 1.0, so I could deploy on the 1.0 CLR. However, I can soon require my users to install the 2.0 CLR without it being draconian. It's really nice to be able to use generics and anonymous methods.

It's a command line app, and I've always struggled with the command line parameter handling. What does a good syntax look like? How should I parse it? I've been rewriting the parser in a more generic way, so it's easy to expand the syntax as the tool grows.

The original implemention has sparse unit test coverage. Of course, retrofitting is hard; your code is no longer well-factored.

However, the new lexer & parser were implemented from scratch, in isolation, and done test-first. I've been using unit testing for TDD, as well as using FIT for acceptance testing. A powerful combination. I just wish I had a pair to make up for all my pesky weaknesses.

The second part is 3 days of comp time (days off), where we get to meet our families, rest, go sailing, etc. Not sure what I'll do with that time... we'll see.