Powershell

public class PSDefaultVariablizer where T: class { string variableName; T innerValue; PSCmdlet cmdlet; public PSDefaultVariablizer(string _variableName, PSCmdlet _cmdlet) : this(_variableName, null, _cmdlet) { } public PSDefaultVariablizer(string _variableName, T _innerValue, PSCmdlet _cmdlet) { variableName = _variableName; innerValue = _innerValue; cmdlet = _cmdlet; } public T Value { get { if(innerValue != null) { return innerValue; } else { return (T)cmdlet.SessionState.PSVariable.GetValue(variableName, null); } } set { innerValue = value; } } } Here is the use case for the class. »

Scheduled tasks don’t have any good way to be edited in Powershell, at least from what I have seen. The other day I set out to write some scripts to help me out. This isn’t really cleaned up or final (aka I haven’t figured out the best error checking yet and it could use a decent refactoring), but I figured I would go ahead and throw them up here to get some feedback. »

I am running Powershell V2 and needed to look through some log files from a bunch of different servers. Powershell V2 and this article showed me the light. gci -recurse | gc | select-string -context 50 "some string to match" > results.txt The context parameter is a Powershell V2 addition that helps give lines above and below the matched string. Select-String is slowly becoming the grep I need in Windows. »

Last week, I posted about how to unit test powershell, which I have been working with a little bit over the weekend. One thing I quickly realized was testing interaction with the pipeline is a must for Powershell. It’s pretty easy to do. Let’s start with the Get-Service cmdlet that ships with Powershell. If you load up reflector, you will see the follow class definition. [Cmdlet("Get", "Service", DefaultParameterSetName="Default")] public sealed class GetServiceCommand : MultipleServiceCommandBase { // Methods public GetServiceCommand(); protected override void ProcessRecord(); // Properties [Parameter(Position=0, ParameterSetName="Default", ValueFromPipelineByPropertyName=true, ValueFromPipeline=true), Alias(new string[] { "ServiceName" })] public string[] Name { get; set; } } Remembering the base test fixture from the previous post on TDD in Powershell, I can quickly write up a few tests that test a few different use cases of the get-service cmdlet with [Test] public void Get_Service_with_single_string_in_pipeline() { // "MySQL" | get-service var name = "MySQL"; var pipeline = Runspace.CreatePipeline(); pipeline.Input.Write(name); pipeline.Commands.Add("get-service"); var result = pipeline.Invoke(); AssertThatPipelineResultIsService(result, name); } [Test] public void Get_Service_with_single_object_in_pipeline_using_Name_property() { //New-Object PSObject | Add-Member NoteProperty Name "MySQL" -PassThru | get-service var name = "MySQL"; var pipeline = Runspace.CreatePipeline(); pipeline.Input.Write(new { Name = name }); pipeline.Commands.Add("get-service"); var result = pipeline.Invoke(); AssertThatPipelineResultIsService(result, name); } [Test] public void Get_Service_with_single_object_in_pipeline_using_ServiceName_property() { //New-Object PSObject | Add-Member NoteProperty ServiceName "MySQL" -PassThru | get-service var name = "MySQL"; var pipeline = Runspace.CreatePipeline(); pipeline.Input.Write(new { ServiceName = name }); pipeline.Commands.Add("get-service"); var result = pipeline.Invoke(); AssertThatPipelineResultIsService(result, name); } private void AssertThatPipelineResultIsService(Collection<psobject> result, string name) { Assert.That(result.Count == 1); Assert.That(result[0].BaseObject is ServiceController); Assert.That((result[0].BaseObject as ServiceController).ServiceName == name); } By using pipeline.Input.Write(), I can write to the pipeline before invoking commands. »

Is it possible? Yes, and it is actually relatively easy. The hardest part can be figuring out how to mock/stub out certain functionality so your testing small units as opposed to full acceptance testing. The line can get blurry, but I don’t really care. Testing is half the battle. But to be clear, the focus of my testing is to test how a snap-in is working. It sounds like an integration test, and maybe it is, but there is no reason you couldn’t test any powershell script using some of the steps outlined here. »

Today I used this function for the first time. Somehow, I have never needed this before. It is super simple and very useful though. It is basically the inverse of DateTime.ToString(“yyyy-mm-dd”). It allows you to parse a custom date/time format. So, for example a Pound proxy log has a date in the format 12/Mar/2009:05:00:36 -0400, which isn’t a standard format in .NET. Using ParseExact, parsing it was a piece of cake. »

“Hello”, “World” -join “ “ Powershell v2.0 has a join operator. It works with simple arrays. Oh well, I still enjoyed creating my own that works with the pipeline. »

Quick and dirty join function for powershell, that utilizes the pipeline. function join { param($delimiter) begin { $strings = @() } process { $strings += $_ } end { [string]::Join($delimiter, $strings) } } The following now works: > "Hello", "World" | join " " Hello World »

There are already a lot of people who have solved this problem, but I wanted to solve it too. Powershell doesn’t ship with a wget‘ish cmdlet, at least that I could easily find. So I decided to kill two birds with one stone, create my first SnapIn and create a Get-Url cmdlet. It’s much easier than I thought. Getting started Start by creating a new class library project. There are two references you are going to need, System.Configuration.Install and System.Management.Automation. »

I spent most of yesterday configuring a server, then delving into the aforementioned error with a few other devs. Here is basically what we did to figure it out, and what the cause was. The error The day started by setting up a new server, and getting our ASP.NET application up and running. At first, the error wasn’t apparent. It was when we started seeing javascript errors on different pages. It looked as though one javascript includes was causing the error, /WebResource.axd?d=KadOK03KouGAGUGwjTWw4w2&t=633707613869062500. »