Why Get-Content Ain't Yer Friend

Well, it isn’t your enemy, of course, but it’s definitely a tricky little beast.
Get-Content is quickly becoming my nemesis, because it’s sucking a lot of PowerShell newcomers into its insidious little trap. Actually, the real problem is that most newcomers don’t really understand that PowerShell is an object-oriented, rather than a text-oriented shell; they’re trying to treat Get-Content like the old Type command (and why not? type is an alias to Get-Content in PowerShell, isn’t it?), and failing.
Worse, PowerShell has just enough under-the-hood smarts to make some things work, but not _everything. _
For example, this works to replace all instances of “t” with “x” in the file test.txt, outputting the result to new.txt:

The Shell vs. The Host

One thing that’s often very confusing about PowerShell is the difference between the shell itself - what I’ll call the engine in this article - and the application that hosts the engine.
You see, you as a human being can’t really interact directly with PowerShell’s engine. Instead, you need a host application that lets you do so. The standard console - PowerShell.exe - is one such host; the Integrated Script Environment (ISE) is another. Those hosts “spin up” a _runspace, _which is essentially an instance of the PowerShell engine. When you type a command and hit enter, the host creates a pipeline, jams your command into it, and then deals with the output.
A number of standardized PowerShell commands actually require the host to implement some kind of command support. For example, most of the core Write- cmdlets actually depend upon the host to do something. Write-Verbose is a great example: The command causes the engine to spew text into the Verbose pipeline; the host is responsible for doing something with it. In the case of the console host, the Verbose text is displayed as yellow text (by default) preceded by the word “VERBOSE:”.
When you develop a script using the ISE or the console (which behave pretty similarly for most of the core commands), you get used to your script behaving in a certain way. If you then move that script over to another host - perhaps a runbook automation system that runs PowerShell scripts by hosting the engine, rather than by launching PowerShell.exe - you may get entirely different behavior.
Here’s a perfect example: most of the “built-in” variables you’re used to working with in the ISE or the console aren’t actually built into the _engine, _they’re built into those _hosts. _For example, since the host is responsible for presenting verbose output, the host is what creates and uses the $VerbosePreference variable. When your script is running in a different host, $VerbosePreference may not exist, and indeed verbose output may simply be ignored. An off-the-shelf PowerShell runspace doesn’t actually come with very much “built-in” at all, so scripts can behave very differently.
It’s pretty important to understand these potential differences. When a developer sets out to create their own host application - like most of the commercial script editors do - it can be very confusing and frustrating, because they essentially have to reverse-engineer much of what the PowerShell.exe console application is doing, so that they can provide an equivalent experience. But you should never assume that a script’s behavior under one host will be consistent in all other hosts; test and verify.

More Summit Speaker Names Leaked

So, I got hold of one of the Summit planning spreadsheets and have the list of speaker names. Now, these folks haven’t yet confirmed, so there are obviously possible changes, but here’s who’ll be invited based on their proposals:

• Augh, they caught me! The complete session list isn’t yet finalized, and there are a few on the “final cut list” that may not actually physically fit, so stay tuned…

Lotta Jasons in there. Hmm, maybe I shouldn’t put Helmick in charge of this again. He appears to be partial. There’s also several slots for PowerShell product team members that haven’t yet been sorted; they may come in a bit closer to the show, once the team has a better grip on their short-term work schedule.
That’s about 63 sessions total. Wow. We’re planning to run continuous sessions from 9am to noon, and then from 1pm to 5pm every day, spread across three tracks. There’ll also be welcome address at 8:15am Monday morning.
Please - tell a colleague. Help us get the word out, because this is going to be _amazing. _

Did you attend the 2013 PowerShell Summit?

I’m looking to hear from folks who attended the PowerShell Summit North America 2013. Specifically, I’d love to hear what you thought of it. What value did you get? If someone were considering attending in 2014, what advice would you offer them? How should they approach the boss? What did you, personally, “take home” from the Summit in the way of new information or skills?
Drop a comment below. Some comments might be re-published as standalone posts as we try to help people understand what the Summit is all about, and why they might want to attend. Thanks!

Why the HECK Do You Want to be Taught .NET in a PowerShell Class?!?!?!

Ok, that post title is deliberately provocative. Twitter and all that.
So look, we’re designed this advanced PowerShell class. One of the top five constant suggestions I get whenever I say “advanced” and “PowerShell” is “.NET Framework.”
And I get it. When there’s no cmdlet, .NET has a ton of goodies that can solve a lot of problems. Maybe you don’t like turning to it, but you’ll do it if you have to.
My problem is, what’s that look like in a class?
I mean, for me, using .NET basically works like this:

Questions about an Advanced PowerShell Class Design

As we continue collecting responses to an outline survey about an Advanced PowerShell class, I’ve come up with a couple of questions and would appreciate any feedback you’d care to leave here.
Keep in mind that we’re a bit bound by this course being Microsoft Official Curriculum. I gotta make sure, in other words, that the average MCT can teach it. Ahem. I also have to face facts that people don’t read or obey course pre-requisite suggestions, and that a lot of people taking the course will have zero programming background.

Help me Design the Advanced PowerShell Class!

I’ve been asked to work on an “advanced” PowerShell class. Now, I don’t like the “advanced” word very much, because it means something different to everyone, depending on their experience. So I’m trying to make the class focus on “powerful, practical things you can do with PowerShell that definitely drift into programming and scripting.”
You can tell me what you think by taking an online survey about the proposed outline, which will be online through October 18th, 2013.

LEAK: PowerShell Summit NA 2014 Speakers

I got a glance at the “short list” of speakers for the PowerShell Summit North America 2014. While none of these names are guaranteed - these guys haven’t even been contacted to confirm - they’ll definitely receive an invite in the next few days.
First up, Mike Pfeiffer. This excites me because Mike’s a former MVP, and now a Premier Field Engineer (PFE) with Microsoft. He _literally _wrote the book on managing Exchange Server with PowerShell, and should be a great addition to our new Domain-Specific track.
Next, Steven Murawski. I’m betting he’ll be asked to deliver talks on Desired State Configuration (DSC), something he’s been playing with intensely at his job. Yeah, production use of DSC.
Ed Wilson’s going to be invited. What’s a Summit without the Scripting Guy?!?!?
Ashley McGlone, too - another PFE, which gives us some awesome from-the-field experience, especially from large-scale environments where PFEs tend to work. Should be awesome stuff.
I imagine I’ll be invited to speak , along with my often-co-author Jeffery Hicks and PowerShell In Depth co-author Richard Siddaway. Richard’s a WMI master, and his talks in 2013 were very well-received. Jeff, of course, is Jeff - it’ll be a fun talk or two, whatever they’re about.
I saw Adam Driscoll’s name on the list (uber-developer with a ton of PowerShell experience), Jason Helmick (I’m hoping he’ll do a deeply in-depth talk on PowerShell Web Access, since he’s pretty much mastered all the not-documented intricacies of setting it up), and a few more.
Early November should see the schedule finalized. Stay tuned.

Seeking Coaches and Judges for the Winter Scripting Games

We’re now seeking volunteer Coaches and Judges for the Winter Scripting Games!
The Games are tentatively scheduled to run for 4-6 weeks starting January 6th, 2014. There will be 4-6 events, each lasting one week.

Coaches

Coaches have access to all teams’ entries and private discussion threads for the week while entries are being developed and accepted. Coaches are meant to log in throughout that one-week period, evaluate what teams have submitted so far, and offer comments and advice in the in-Game discussion thread.

Coaches’ comments receive a special flag, helping teams focus on them quickly. Note that teams are not required to use the in-Game discussion thread - they can discuss via email or elsewhere. Teams are also not required to continually submit entry files for coach review, so for some teams, coaches will have nothing to offer.
Team discussions are private to the team members and coaches; discussions will not be made public.
We’ll accept as many coaches as want to participate. Note that you cannot be both a coach and a judge, and coaches are not permitted to participate on a team as a player.

More Congrats!

Another kudos to Jon Walz, host of the long running PowerScripting Podcast, for his first and well-deserved MVP Award!