ScriptCS or PowerShell? part 1

§ May 15, 2013 13:02 by beefarino |

TL;DR: Use both:

A few days ago I posted a teaser of a project I hammered together that allowed you to run ScriptCS inside of your PowerShell session.  This morning I pushed the cleaned-up version to to GitHub:

I’ve been watching ScriptCS with much interest – I’m a huge fan of scripting and REPL interaction and having another environment to leverage makes me happy.  What makes me sad is when I read crap like this on twitter:

ScriptCS is awesome!  <expletive deleted> PowerShell!

Or this:

PowerShell is amazing and ScriptCS is teh suck!

Why anyone would shun one or the other is beyond me.  They each have a wealth of possibility to offer.  My first instinct with new technology is to figure out how to make it work with other things I already know.  This helps me understand the guts of the new thing and gives me a frame of reference to move forward.  So that’s what I’m doing, and the potential is tantalizing.

Phase One

Phase one was pushed to GitHub this morning.  You can now run ScriptCS code inside of a PowerShell session:

PS > ipmo scriptcs
PS > invoke-scriptcs '"Hello PowerShell!"'
Hello PowerShell!

You can even pipe data to ScriptCS and consume it:

PS > 0..9 | invoke-scriptcs '(int)pscmdlet.Input[0] + 100'

And put data from ScriptCS onto the pipe:

PS > 0..9 | `
    invoke-scriptcs '(int)pscmdlet.Input[0] + 100' | `
   %{ "Output: $_" }
Output: 100
Output: 101
Output: 102
Output: 103
Output: 104
Output: 105
Output: 106
Output: 107
Output: 108
Output: 109

There’s still lots to do, but the possibilities are pretty amazing.  Ever wished you could use LINQ from PowerShell?  Now you can:

PS > invoke-scriptcs -input (0..9) -script 'from i in pscmdlet.Input where (int)i > 5 select i'

Phase 2

Phase 2 is pretty much the opposite of what I’ve done so far.  Phase two is a Script Pack for ScriptCS that allows you to run arbitrary PowerShell script in ScriptCS.  This is working now – the plan is to clean it up over the next week and make it public.  Stay tuned…

Yo Dawg I Heard You Like Scripts So I Put Scripts in your Scripts

§ May 13, 2013 12:56 by beefarino |




























Because reasons, that’s why.

CodeOwls Skunkworks at the AZ PoSh User Group

§ April 30, 2013 09:17 by beefarino |

white-compass-rose-hiTomorrow evening I’ll be giving an online presentation to the Arizona PowerShell User Group.  I’ve heard great things about this group and am really looking forward to the talk – if you want to join the fun check out the details here:

The topic is “Strange Things with PowerShell”.  Well, that’s the title – the topic is really a set of skunkwork projects I’ve been hammering out since the beginning of the year.  I’ll introduce them briefly in this post, but if you want to learn more you’ll have to tune in tomorrow evening or wait for the release.

The first project I’ll be covering is the Entity Shell (ES).  ES is a PowerShell module that “knows” all about Microsoft’s ORM named Entity Framework.  Basically, once you have an Entity Framework data context defined, you can use PowerShell to manage your entities without doing any extra work.  Here’s a working code snippet to whet your appetite:

# pull in the entity shell
import-module entityshell;

# pull in my entity data context
new-psdrive -name ent -root '' -psp entityprovider `
    -context [SuperAwesomeWebsite.Models.Context]

# create a set of 100 new user accounts for testing
0..99 | new-item -path ent:/users -username { "User$_" } -password { "Password$_" }

# commit the new entities to persistent storage

# server-side filter for users without a password
$u = dir ent:/users -filter "it.Password IS NULL" 

# generate a report of these users
$u | convertto-csv | out-file "badusers.csv"

# remove the offending users
$u | remove-item

# commit these removals to persistent storage

The other project I’ll be demoing is Polaris; this project came about as a way to see how simple I could make the process of extending Windows Explorer.  Shell namespace extensions are hard; Polaris makes it dirt simple, and all you need is a little PowerShell to turn Windows Explorer into a rich dashboard of the stuff you want to see.

More on these projects in the coming weeks; in the meantime, if you want to see the goods, you’ll have to tune in (

PowerShell Mini-game: Equality (Answer and Winner)

§ April 17, 2013 19:38 by beefarino |

Many thanks to everyone who contributed answers to this little puzzler!  I was actually a bit surprised at the volume - hopefully you found it fun and educational.

First, let’s get a definitive answer down for this one…


In PowerShell, when is the following statement true? Explain why.

     ( $a -eq $b ) -ne ( $b -eq $a )


At first glance this may not seem possible.  The trick is in understanding how PowerShell evaluates the equality operation when the types of $a and $b vary. 

There are two general cases to consider here: when $a is scalar, and when $a is an array.

Scalar Equality and Type Conversion

If you’re not familiar with the term scalar, I’m using it to mean a variable containing “a single value” as opposed to an enumerable collection type, such as an array or list.  Yeah, it’s from Perl, so what?  (Note that the string type, while technically an enumerable collection of characters, is considered a scalar value here.) 

Type the following in your PowerShell console (seriously (I SAID DO IT)):

$a = 0;
$b = '';
$a -eq $b

What do you get?  True!  Which makes sense, since 0 and an empty string both sort of mean “nothing” or “no result,” right?  Now type this:

$b –eq $a

Boom goes the dynamite: False.  So what’s happening here?  It may help to replace the variables with their actual values:

0 –eq '' # true case
'' -eq 0 # false case

When PowerShell evaluates this comparison, it begins by taking the left operand at face value.  Since the right operand is of a different type, PowerShell is forced to coerce its type to match the type of the left operand.  The reason for the false case becomes fairly obvious when you spell out the conversion PowerShell is doing on your behalf:

0 –eq [int]'' # true case
'' –eq [string]0 # false case

In the true case, the conversion of an empty string into an integer value of 0 makes sense, and the equality expression is true.  In the false case, the conversion of the number 0 into a string results in a string containing a single character ‘0’, which is different than the empty string and the expression is false.  You can verify these conversions in your console:

[int]''   # 0
[string]0 # 0

This hidden coercion can lead to some fairly interesting results, to put it mildly.  Try this one, it’ll blow your mind:

$a = $null;
$b = [string]$null;
$a -eq $b

Yep, that’s right: ($null) doesn’t equal ($null cast to a string) in PowerShell.  Have you ever passed $null to a .NET method that accepts a string?  No, you haven’t: you’ve passed an empty string without knowing it…

Arrays and –eq

Several puzzlers pointed out that –eq behaves differently when the left operand is an array; while not the answer I was looking for it’s just as correct as the previous one.

The easiest way to describe this is by example; try this in your PowerShell host of choice:

$a = 1,2,3,4,5;
$b = 3;
$a -eq $b
$b -eq $a

When the left operand is an array, –eq returns the members of the array that equal the right operand.  In this case, $a –eq $b returns the integer 3.  Reversing the order of operands naturally changes the expression, and since there is no way to convert an array of numbers to a single integer the comparison is false.

This is an awesome example of PowerShell’s penchant for lists and enumeration, and it applies to many of the binary operators it supports:

'aabb','bbcc','zzaa' -replace 'a','q'

The Takeaway

The lesson here is that while PowerShell isn’t a strongly-typed language like C#, it does have solid roots in the .NET type system and leverages it in many interesting and “helpful” ways.  If you’re not careful, you’ll get burned.


Ah, I almost forgot!

Choosing the winner on the merit of the answers turned out to be tough – everyone did a really great job.  Some explanations were better than others, but it was difficult to isolate one as the best.  Thankfully I have PowerShell's get-random to turn this into a “business decision.” 

And the author of the winning answer and receiver of a license for the immensely cool SeeShell software module published by the devastatingly handsome folks at Code Owls is….




Thanks for playing everyone - since this was so much fun let’s say we do it again soon.  For now though, focus on those upcoming Community Scripting Games!