Why do such a thing? Well, if you’ve created your own aliases for commands and you try to give someone your ps1 script file, it will not run because they have not got the same aliases defined as you. Also, scripts that use fully-resolved names like “Get-ChildItem” are more readable for a newcomer to PowerShell than one that is using the unix-like “ls" alias for example. "Get-ChildItem" leads quite directly to the MSDN documentation, but "ls" might lead you anywhere. Before you publish a script online somewhere for the world to use, it’s important that you try to remove any aliases and replace them with the native command names.

Doing this kind of thing has been talked about before but it was always a very difficult thing to do with PowerShell v1.0, what with the lack of BNF documentation describing the grammar etc. Thankfully, it's a lot easier to do with PowerShell v2.0 (currently at release CTP2) because the team has exposed the Tokenizer for use in scripts. There's been suprisingly little use of it so far, so I figured I'd start the ball rolling with a series of articles based around it. So, let's look at an example script that uses aliases and put it through the meat grinder:

As you can see, it spits out the expanded script to the output stream. The informational messages are written to the host, so they won't interfere if you redirect the output to a file like: .\resolve-aliases.ps1 in.ps1 > out.ps1

Here's the Resolve-Aliases.ps1 script itself:

Of course, this requires PowerShell v2.0 CTP2. Next in the series, I'll give you a script to check your ps1 scripts for backwards compatibility against PowerShell 1.0. That should be handy for those naughty admins out there who despite all the warnings have installed v2 in production.

Someone on a private mailing list I'm on lamented the problem with powershell's '>' redirection operator defaulting inflexibly to use unicode for encoding the output file. This is not very compatible for NT's ancient console subsystem which works best with ASCII data. Fortunately, there's an easy workaround to fix this:

Due to the magic of command discovery and the fact that > really does use out-file, you can "fix" this by placing the following in your $profile:

function out-file($FilePath, $Encoding, [switch]$Append) {
$input | microsoft.powershell.utility\out-file $filepath -encoding ascii `
     -append:$append
}

From now on, > will be forced to use ASCII encoding. This works because functions have higher precedence than built-in commands in powershell's command discovery search.

UPDATE: Rather annoyingly, I'm informed that this particular workaround doesn't work on v1.0 of PowerShell. I tested the above on v2.0CTP2 only. Doh.

Just another quick-fix post for any readers’ benefit. I have been using MOSS on Windows 2008 Server on VMWare for a while now and the display has always been sluggish and choppy even though VMWare tools is up-to-date and installed. I decided to take a quick peek at the display properties to see if perhaps hardware acceleration is off or something like that and I noticed that the display driver was “Standard VGA Display.” I thought to myself, “Shouldn’t that be a VMWare display driver?” so I clicked properties and drilled down to the “Update Driver…” dialog. Clickety-click and hey presto, it finds a newer driver, namely “VMWare SVGA II” and installs it. Display is now much better. On other guest OS’s like Win 2003 etc, VMWare tools installation updated the driver for you, but this time it didn’t. Not sure why.

One remaining problem I have is that the mouse is dodgy and sometimes the host mouse pointer gets de-synced with the guest’s. Anyone got that problem?  Fixed by starting device manager and going through nearly the same drill as the display driver. I manually chose “VMWare Pointing Device” and rebooted, replacing the default ps/2 mouse driver.

Update:

After I rebooted, it was still a little sluggish. Then I remembered that by default, hardware acceleration is only at one notch up. So, push it up to full!

MoW poked at me, so I guess I can’t let the crazy dutchman down:

How old were you when you started using computers?

10 or 11

What was your first machine?

An Amstrad CPC 464 with Green screen.

What was the first real script you wrote?

I vaguely remember being delighted at having a rocket (Chr$(239)) ascend the Amstrad’s screen when I figured out that STEP –1 was the key in getting a for/next loop to count backwards.

What languages have you used?

• Powershell, VBScript, JavaScript, Tcl, Perl, Batch/4NT
• Z80A, 8088/8086 (NECv20/v30) assembler
• Basic, Turbo Pascal, Turbo C, C++, Java, C#, VB.NET

I’m a bit of a jack-of-all-trades when it comes to development. The list above is just what I can remember

What was your first professional Sysadmin Developer gig?

After helping out a friend’s dad put together a training course for Visual Basic 3.0, I then managed to blag a job coding Ireland’s first ever major e-commerce site using MS Merchant Server 1.0 (which predated ASP 1.0) for a leading ISP.

If you knew then what you know now, would you have started in IT?

I might have started a little bit earlier even!

If there is one thing you learned along the way that you would tell new Sysadmins (or Devs), what would it be?

Just one thing? Learn Regular Expressions as it will pay you back ten-fold for whatever time you put into it.

What is the most fun you have had scripting?

There’s only one answer here: writing extensions for PowerShell.

This particular branch of the meme ends here as I don’t think I can tag anyone who hasn’t been tagged already.

Just a quick one for the frustrated searchers out there. If you've recently installed the SP1 beta for Visual Studio 2008 (or just the 3.5 sp1 beta alone), and you find that you have serious difficulty using SharePoint Designer 2007 against a remote instance of SharePoint running in a VM (or a physical machine) that doesn't have the SP1 Beta bits, you know what to do. My SPD would refuse to load the master page from my virtualized SharePoint instance until I had installed .NET 3.5 SP1 Beta onto the virtual machine also. Just so you know!