More Snippets but being Verbose


So this is another 101 level post. Most of my scripting has been for automation and I try to  debug enough that the code is ready to go. I have dabbled with Verbose messaging and normally it didn’t apply so I was easily distracted. I added a personal ToDo, learn to use this handy feature. Quick note, when I have written GUI’s for my scripts. Since they are written for other uses some messaging was in order to save me some helpdesk calls about it. In short I would add a StatusBar with text regions and I would basically add Verbose like messages there. Moving on…

TLDR; so guilty here as I started with If statements and check for Verbose and then change $VerbosePreference, write the message and then set the $VerbosePreference back to where it was. See, this is why I bailed. I also walked on kitten-shells around the write cmdlets with all of the back and forth about write-host and it killed kittens. Focused, let’s do this.

First step: remember the code you should always be adding to your Scripts and Functions

Param ()

Again you should be preferencing your scripts and variables,  these  two lines of code make your code “Advanced”.

How does this help? Being an advanced Script or Function you immediately have access to “Common Parameters” and with that Verbose parameter is inherited. No let’s risk the ridicule and look at that Write-Verbose cmdlet.

Write-Verbose -Message "Okay you are in the Begin block"

That was all it took. No need for If statements or sub-functions… just use that cmdlet.

Since the operator is running in Verbose mode I will be adding this line of code I will be adding this very often. I ran a few test runs and I wanted to include the Lifecycle Block the message is coming from so I started to format the message with [BlockName]Message text. like:

Write-Verbose -Message "[BEGIN]Okay you are in the Begin block"

Admittedly I have seen this on petri and just saw it as a great practice. Lots of manual typing right. How do  we make that easier? 3.2.1 Snippets!!!!

I added the following to my PowerShell.json file:

<div>        // Adds verbose messaging in the BEGIN block</div>
<div>        "Add Verbose in Begin block": {</div>
<div>            "prefix": "verbBEGIN",</div>
<div>            "body": ["Write-Verbose -Message \"[BEGIN]${1:Message}\""],</div>
<div>            "description": "Add verbose messaging for activity in the BEGIN block"</div>
<div>        },</div>
<div>        // Adds verbose messaging in the PROCESS block</div>
<div>        "Add Verbose in Process block": {</div>
<div>            "prefix": "verbPROCESS",</div>
<div>            "body": ["Write-Verbose -Message \"[ROCESS]${1:Message}\""],</div>
<div>            "description": "Add verbose messaging for activity in the PROCESS block"</div>
<div>        },</div>
<div>        // Adds verbose messaging in the END block</div>
<div>        "Add Verbose in END": {</div>
<div>            "prefix": "verbEND",</div>
<div>            "body": ["Write-Verbose -Message \"[END]${1:Message}\""],</div>
<div>            "description": "Add verbose messaging for activity in the END section"</div>
<div>        }</div>

So while in VSCode, working on some code I can type verb and I will see the snippets for each LifeCycle Block. I select the appropriate one, the snippet text is inserted into the code and the message that follows the Block name is highlighted for editing and press tab and I am done.

Something like this:

VSCode - Verbose Message


Distraction for Today – Snippets for VSCode


Current project for the PowerShell VSCode project is opening the Snippets up to the community and for the community. The was announced in the VSCode channel in the Slack group, a resource I strongly recommend.

I have taken the great base snippet file Keith Hill provided in the early days of using VSCode as my PowerShell editor and converted my ISE snippets from the XML file. I can’t complain as I had a useful collection of code snippets for ISE but looking at the format and capabilities that VSCode provided, I quickly started adding my snippets to the base collection Keith Hill provided.

I have one that I like to include in my End statement of a script. As it stood it was usable but was lacking. Watching the community post snippets I saw a chance to take this little nugget and make it better. The code simply starts a remove-variable so I can clean up variables before the script finishes and  then initiate a garbage collection via .Net. Below is what the snippet looked like when I used in my code:

 END {
    Remove-Variable -Name varA, varB, anotherVar

I call the snippet and the code is added, including the tabs and carriage returns. The text area after the Name parameter is where the cursor goes because of  ${1:variablestoberemoved} but that is far as the Snippet automation would go. So I created an empty JSON file and started with the snippet as I had entered it. Then I progressed with fixing and adding some pieces to the snippet. I would then take the new version of just that snippet and replaced the one in the PowerShell.json file, then in a blank script file I would use the prefix and check the progress.

// Original
“Initiate Garbage Collection – Original”: {
            “prefix”: “freememory”,
                “Remove-Variable -Name \\$variablestoberemoved\r”,
            “description”: “Free up memory when script completes”
    // Now let’s write that with a “tabable”
    “Initiate Garbage Collection – Next”: {
            “prefix”: “freememory”,
                “Remove-Variable -Name \\${1:variablestoberemoved}\r”,
            “description”: “Free up memory when script completes”
    // That sort of worked but after I enter the variables I want to table
    // tap out of the code because this is done
    // What I finally came up with
    “Initiate Garbage Collection”: {
        “prefix”: “freememory”,
            “Remove-Variable -Name ${1:variablestoberemoved}\r”,
        “description”: “Free up memory when script completes”
So through the progression testing, I can call the snippet, it will take me to the “variablestoberemoved” enter the variables, comma seperated, that I know will still exist, then I can hit tab will take me to the line after my snippet text. Looks like:
Quick use of a PowerShell snippet in Visual Studio Code

CLI – Windows Terminal – Settings

Not just PowerShell but this is something I have observed as I work with the Windows Terminal (Preview) app. I have used a few different terminal apps but really liking this one.

There are a few things I hope change as the app matures, note it is still Preview. The group working on this app have been very responsive and small changes have been rolling out in a quick manner. For example they have released a font to be used with the terminal. As someone how likes a slashed zero I have been using alternate fonts for the CLI and VSCode but this new font is a great start for those that have not been digging that deep.

My biggest frustration with this app has been centered around the settings file. With each update the list of changes is well documented but when you try to match them up to your instance … yep that is my frustration. I have done the app uninstall and remove the current settings file (profiles.json) and re-installed. That brings the new stuff to surface but now I have to go back and add all of my ssh profiles… Then I came upon a nugget of information and thought I might share that in case there are others finding the same frustration. In the video below I try to show how to find some of the new settings that you might not see after an app update. While in the terminal hold the “Alt” key and then click on the Settings item in the terminal tab menu. This opens a file names defaults.json. Going through this file helps you find the pieces you can then apply to your active settings (profiles.json).

Finding tidbits; this community is great

Powershell + DevOps Summit 2019 has been going strong this week. Sadly I am unable to attend events like this so I do what I can to follow the action. One of the ways I follow it is via constantly updating a Twitter search for #PSHSummit. This has been a great feed of information.

One of the posts, not sure if it is specific to the Summit but was a quick tip like statement that made me say “dang”. I will go further with where I went with the content in an upcoming post but I just wanted to ink (digitally of course) my thoughts on it.

I am a Systems guy, we learn how to do things, we jot it down and then we “automate” it. No matter the shell, we create these scripts. In my case, they started as just lines of commands.

Time, many years for me, passes and we start sharing these and we begin to not only take pride in the actions of our scripts but we start adding comments, looking at the layout etc so that when we do share our work we have a little more pride.

With PowerShell and probably more so the editors we start utilizing we go even further with the format of the script as much as the complexity of the work it is performing. It is still evolving.

So this nugget touched on declaring variables, specifically for a file object. Ouch, I can just look at the code I was working on at the time and say…. [System.String] was what I was using to declare a variable for just that… Yes it works, but why didn’t I just go the extra step (and again with the editors/IDE’s available today it is right there) and declare it as FileInfo or DirectoryInfo. Lesson learned.

I mentioned an upcoming post because as soon as I read that I had to start testing… for the simple use of [System.IO.FileInfo], in just the script I was working on I could reduce lines of code I used right then and there…

End of the day… code looks cooler and I have a sneaky suspicion the execution of the code will be more efficient.

Thanks Mr Ruddy.


Let you IDE dress it up

I am re-posting something I posted in a small Slack group.

I started with showing how easy it can be to let your editor (in this case VSCode which personally I can’t see why you would be using anything else but …) come in and make your code look right. Let’s face it, we have an idea for what we are coding, and we want to stay focused on that. Between interruptions, writing, testing, writing again just focus on the task at hand is ideal. One thing that can help with that is the code formatting capabilities of your Editor/IDE.

So in the first video I have a simple scratchpad script where I am testing an If\ElseIf statement versus a Switch statement. There is nothing special in the code, matter of fact it just might be flawed, hence why it is a “scratchpad” script. The point is I was working through and then used Format Document to dress up the code (I believe there is also the use of “Trim Trailing Whitespaces” involved as well).

So as you see the format did dress up my sloppy code but I was not thrilled on how that destroyed my concise switch statement elements. Yes it formatted according to the settings in my settings.json file but…

I kept thinking about that scenario and then I remembered the setting that would probably work through this. In the following video I show the same code, format and the destruction, I mean expansion of my switch elements, Ctrl-Z, change the setting and the Format Document works to my liking…

So I stay in OTSB but because they are simple elements my Switch statement stays just a few lines.

This applies to other languages in Visual Studio Code but this is a PowerShell blog so… If you are using Visual Studio Code for PowerShell work, go into your Settings file (Use the ⚙ icon and select settings and then search for “PowerShell Code Format” .  When you get to the Code Formatting: Preset check here for a great reference when you select the formatting style.

Again, I welcome any questions or feedback you might have. Now back to work.



Warning: Venting over VSCode Install

I spent a good portion of time coming up with a scripted process to help some colleagues to make the move from the ISE to VSCode. It was hard enough to get some to see the value of PowerShell and now to get them off the PowerShell ISE…

Give them a nice clean install of VSCode with extensions, modules, snippet file, settings…

The install-vscode from PSGallery was a great way to automate it with Build Type, Architecture and include extensions….

Now VSCode prompts you to use a different (User versus System) install. Easy enough to download the file or use from a shared location but I have looked at both and I just don’t see a need for this variation or even the prompt…

Starting over again…

Checking your installed modules versions

Okay in a bit of a rush and should have posted this one some time ago. In a rush because I  was led along the lines ( thanks Bret Miller ) of using a GitHub Gist to better display (and share) code that I include in posts…

Yes this is very version 1. It was simply a utility I started writing for my own use. Then I found some folks who were running old versions of certain PSGallery installed modules like msonline, ImportExcel or the plethora of Azure Modules. Admittedly I watch Twitter and RSS feeds all day for PowerShell so I was rarely surprised by the results.

The code is a PowerShell function so it can be easily deployed. I recommend placing it in your profile (old school I guess but I still prefer profile.ps1) so you can call it in any PowerShell session.

Function show-installedmodules {
#Requires -Version 5
$varModules = (get-installedmodule)
Begin {
"-" * 52
"`tReporting on {0} modules" -f $varModules.Count
"-" * 52
}# End Begin
Process {
$varModules |
sort-object -Property Name |
select-object -Property Name,
Label = "Online Version";
Expression = {(find-module -Name $_.Name).Version}
} |
format-table -AutoSize
}# End Process
Remove-Variable -Name varModules

Recently, well after I  slapped a similar function together for auditing my chocolatey installed packages, I started to look at the next version. After making notes and  beyond  bad code I saw a few things so I am starting a new project to improve it. One quick upgrade will be making the display smart to show the primary module (for example VMware.PowerCLI and not all the sub modules that are part of PowerCLI) only. So now I am looking at creating the project (and learn how to use github projects). My next version will not display to the console with any great expertise like @jaykull but here is a rough version:


Snippets – A Lesson Learned

Not the  first and probably won’t be the last but since I was talking about VSCode snippets. I started working on one for creating a [Parameter] statement to make building a Param() section easier. Was cool to provide a dropdown box for a variable (so lesson learned but not the subject of this) and now it is time to test it.

First debug, for that list of choices… at first I had |True,False| but I found using |$True,$False| just looked better, personal choice. Testing continues. Part of the snippet includes [VariableType]$variablename. A possible variable type is “PSObject” but looking at the snippet this should work right?

<div>        // General Parameter Definition</div>
<div>        "Parameter Statement": {</div>
<div>            "prefix": "paramStatement",</div>
<div>            "body": [</div>
<div>                "[parameter(Mandatory=${1|$True,$False|}, ValueFromPipeline=${2|$True,$False|})]\r",</div>
<div>                "\t\tHelpMessage = \"${3:HelpMessage}\")]\r",</div>
<div>                "[${4:VariableType}]$${5:VariableName}"</div>
<div>            ],</div>
<div>            "description": "Scaffold for Parameter creation"</div>
<div>        }</div>

I would type PSObect and the snippet menu would come up as I type pso… Ugggh. Then it dawns on me I had created a snippet months ago for creating Custom PS Objects and the prefix was … psobj. Lesson Learned, even Snippets have reserved words 🙂 !

Sharing – Just my two cents

In my RSS Feed I saw an article , from an author I respect a great deal. This is  just the latest  that just puts me in a quandary. A few months I wrote a script for this function. I struggled with it a few more days fighting with the two versions (Stable and Insiders) to include instances where both are installed. Then I tried to take it one step higher… if snippet is updated locally copy that to github.

Lots of chatter about sharing came out of the PowerShell Summit. Please take no offense but … Most of this comes from the fellow early adopters who could be brutal during “The Scripting Games” and other public forums (see all of the conversation about Write-Host and puppies or kittens whatever it was  when it started). Sure I learned reading the judge’s critiques but they didn’t come off as recommendations or teaching moments. Another person I respected greatly came out with ScriptCop and my insecurity but it was always a kick in the face. Sure PSScriptAnalyzer is basically the same but over the years I get the intent and use it as a guidance.

My own petty insecurity but I don’t share my work publicly, to include blogging. I know they work but might not be perfect. I also have to admit I grind my teeth when I see some posts hit my my RSS Feed. No splatting, backticks, etc. On the same hand I have fought to lead PowerShell training in the places I worked, created  a Slack group for PowerShell but localized to the area I live in. I do love the community and can respect the push for sharing but I think there is talent out there stage shy or maybe even gun shy.