PowerToys v0.77.0 made its debut earlier this week. A cool new facility also showed up — namely, Command Not Found. This nifty PowerShell module “detects an error thrown by a command and suggests a relevant winget package to install, if available.” You can see that capsule summary in the screencap shown above. What I have learned is that Command Not Found requires installation, but also carries some dependencies as well. Thus, Bringing up PowerToys “Command Not Found” tool involves a little more work than other new items added in the past. It’s all good, though…

Steps in Bringing Up PowerToys Command Not Found

As you can see in the intro graphic above, Command Not Found (CNF) must be manually installed before it does anything inside PowerShell. This is simply a matter of clicking the install button shown at mid-right in that image.

And there are a couple of buts (pre-requisites, really):
1. Right now, CNF works only with PowerShell v7.4.0 or higher. If it’s not installed and running, that must be fixed.
2. CNF also relies on a PowerShell Gallery module named WinGet Client Module (ID: Microsoft.Winget.Client). Interestingly winget does not install PS Gallery items, but there’s a button in the PowerToys console shown above that will handle this for you. After it’s installed, you can check the CNF install logs or use the Get-InstalledModule cmdlet (another PS Gallery item).

The Get-InstalledModule cmdlet displays all PS Gallery items in your profile.

If you’ve not yet defined a PS profile, this installer will report its absence. But don’t worry: running the CNF installer creates one for you. Thus, once you get past the pre-requisities (dependencies) and install CNF, it’s almost ready to use. You’ll need to refresh the current PS profile so it brings CNF into the runtime environment for Windows Terminal/PowerShell. The easiest way to do that is to close Windows Terminal, then open it again. When you type an unknown command into the prompt, PS will offer to install it for you as long as it can find a valid source. That’s what you see in the next graphic:

The vim utility is uninstalled on this PC, so CNF shows potential install strings. [Click image for full-sized view.]

Note: Demitrius Denelon used vim as his example in touting this new capability for PS users, so I had to find out what it was. As its name led me to suspect, it’s a modified version of the ancient “vi” text editor that you can run inside PS. Use winget show vim.vim to see more info.

Cool New Tool

This is a great new addition to PowerShell. This heightens my willingness to experiment with and learn about new cmdlets. Now I know if I bang on an uninstalled PS Gallery item, this facility will tell me how to install it so I can use it right away. Mmmm good!

When a new version of PowerShell comes along, it’s always interesting to see whether or not winget can field that update correctly. This time around — with version 7.4.0 — it reports a “different install technology” as you can see in the lead-in graphic. When the PowerShell install method changes, winget won’t handle the update without an uninstall/reinstall maneuver. So I CTRL-clicked the link shown above the WT pane (from the GitHub link that’s helpfully provided) and used the MSI file to update PowerShell instead.

When PowerShell Install Method Changes, Use GitHub

That Microsoft Installer File is under 65MB in size. On my test PC, that takes less than 10 seconds to download. That opens the “SuperHero” PS installer (see next screencap), after which install takes half-a-dozen mouse-clicks to configure as I like it. Another minute or so, and the job is done. MS is doing better at getting new versions of PowerShell to circulate. I like it!

The only time you actually see the PS superhero avatar is when the installer runs.

Watching Out for Certain Winget Shenanigans

So, I’m learning to be wary of three specific installs when using winget inside Windows Terminal and PowerShell — namely:

• winget itself: if the tool doing the updating gets updated, interesting things can — and do — sometimes happen. This is another case when I’ve sometimes seen the “Cancelled” error message that really reports a loss of interaction with the updater (the update actually succeeds, but can’t report success).
• Windows Terminal: same principal as before, write large when the entire Windows Terminal runtime has to change. When this occurs, WT usually writes a message into the active terminal window to say “Restart the window/session to run the changed version.” Good -oh!
• PowerShell: and again, if PowerShell is updating itself it must be ready to handle those changes. As we see in this particular case, something has changed that requires an uninstall/reinstall. My preference: using the GitHub installer instead. Easy-peasey.

And that, dear Readers, is how I often keep myself entertained, here in Windows-World. Great fun…

Here’s an interesting one. After running winget upgrade on Friday afternoon, I noticed something interesting. Even though I’d already upgraded that particular PC to PowerShell version 7.3.9, it still showed a version of 7.3.8 in need of an upgrade. Immediately, I started sussing out doubled-up PowerShell. As you can see in the lead-in graphic it was a case of “parallel versions.” Even though 7.3.9.0 is clearly installed (PowerShell 7-x64), so is 7.3.8 (PowerShell 7.3.8.0).

After Sussing Out Doubled-Up PowerShell,
Bye-Bye 7.3.8!

Turns out that 7.3.9 has some install changes. That means winget won’t simply upgrade the software. One must run winget uninstall, then winget install to do this particular round of the PowerShell upgrade dance. You can see this at work in the next screencap, which shows:

(a) notification from PowerShell that a new stable release is ready for download (white background against black text up top)
(b) notification from winget that “install technology is different” for new PowerShell release, so uninstall/install maneuver is needed

PowerShell is pretty clear that winget upgrade can’t handle this without extra maneuvers.

Thus, one approach here would be to run this sequence of wingets:

winget uninstall Microsoft.Powershell
winget install Microsoft.Powershell

The first removes the old version and the second installs the current (new) one. Easy-peasey, right?

Take the Long Way Home

The way I see things, there’s another choice when this kind of thing happens. The PowerShell installer file at GitHub (or the equivalent link shown at the top of the screencap: https://aka.ms/PowerShell-Release?tag=v7.3.9) not only installs the new PowerShell version, it also removes the old one. So I went ahead and ran PowerShell-7.3.9-win-x64.msi on the same machine where I captured the preceding screencap. I closed PS manually, instead of having the installer do it. Then I ran winget upgrade again. And sure enough, the doubled-up version once again appears!

It gets more interesting. I ran winget uninstall MIcrosoft.PowerShell –version 7.3.9.0 to remove the older version. This time, I let the (un)installer attempt to close PowerShell. It failed, and showed an “uninstallation abandoned error” (see next screencap).

Winget drops the ball trying to uninstall the newer version from inside that version! [Click image for full-sized view.]

Go with What Works

OK, I want to run the new version. But I also want to remove the older one. That cycles me back to the original screecap at the head of this blog post. If you go to Settings → Apps → Installed apps, you can easily excise older PowerShell versions from there. So that’s what I did. And presto: no more winget notifications that 7.3.8.0 needs an upgrade to 7.3.9.0.

One more thing: on another test machine (one running a preview version of PowerShell) I successfully used winget to uninstall 7.3.8.0 and then follow up with a successful 7.3.9.0 install. I think this worked because PowerShell 7.3.9.0 didn’t attempt to uninstall or install itself. That said, I did also have to manually install a new profile so I could make 7.3.9.0 my default PS selection afterwards. It’s always something, right?

Note added November 1: Do It From Command Prompt

On another test PC just now, I opened Windows Terminal. Then after opening a Command Prompt tab, I closed the open (default) PowerShell 7.3.8.0 tab. After that I was able to use winget to uninstall the older PS version and install the new one. This required no  new profile shenanigans. It’s my recommended approach until the PS team gets this fixed (I got confirmation from an MS contact yesterday that yes, this is a known thing and they’re working on it).

I’ve just completed a fascinating project for TekkiGurus: a five-part series on customizing and extending Windows Terminal. For the 5th and final part, I decided to build PowerShell scripting that would handle such customizations I use as don’t fall under the settings.json umbrella. Ironically, one of those tasks involved editing that very file to change the default font. That’s when I saw syntax erors derail PowerShell JSON edits, as shown in the lead-in graphic. Let me explain…

How Did Syntax Errors Derail PowerShell JSON Edits?

I started off my project by asking Copilot to present me with some initial PowerShell commands to handle the following tasks:

1. Download, install and set up Jan DeDobbeleer’s outstanding OhMyPosh prompt customization tool. This turns out to be a more complex task than it might seem, because it requires downloading, unzipping and copying Nerd Fonts into C:\Windows\Fonts, adding an invocation to the PowerShell Profile script, dealing with OhMyPosh, and then selecting a Nerd Font as the WT default.

2. Download, install and add the colortool executable to a default Windows path. Colortool is a GitHub project that provides information about Windows Terminal color assignments for text and text backgrounds. This one was pretty straightforward.

3. Install the winfetch utility that shows WT color schemes, system info, text colors, and a few other odds’n’ends. This required only one line of code, so easy-peasey.

The error showed up at the end of my PS sequence for the OhMyPosh tasks (I’ll refer to this as OMP from now on). Seems that Copilot’s code included two errors that it took me some time to find. First, the object sequence for the default font that OMP required turned out to be the string “.profiles.defaults.font.face” rather than the truncated version that Copilot provided (“.profiles.defaults.font”). Also, it used an alias for the default Nerd Font I chose rather than its full name — that is “CaskaydiaCove NF” instead of “CaskaydiaCove Nerd Font”. Interestingly, this alias worked in Windows 10, but not in Windows 11 (there, only the full name would do).

Errors Found Are Easily Fixed

It took me a while to figure this out because I couldn’t find exact documentation to match my problems precisely. I figured out the object sequence by examining the json.settings file from another Windows PC that had the default already set and following the sequence of the object name hierarchy in use in that file. In other words, I noticed a face property in that file that was missing from my rewritten json.settings file. No wonder it wouldn’t save.

Once I made that change, I got another error message (from Windows 11) that reported it couldn’t find a font named “CaskaydiaCove NF.” I so looked in C:\Windows\Fonts, and sure enough the font name in Explorer is actually “CaskaydiaCove Nerd Font.” And again, once I made that change things worked properly.

As the old saying goes: “It’s always easy when you know how.” It took me a while to get to the last detail in the “how” part, but indeed, it was dead easy after that. Things go that way a lot in Windows-World, especially when writing code or command line instructions. I’m just glad it’s working now!

One More Thing: Replacing Munged JSON File

On the machine where I made the object reference error, settings.json remained munged. It kept throwing errors each time I started up WT or PowerShell. So I  researched the topic and learned that if you open settings.json in a text editor, then delete the whole thing, WT will rebuild that file from programmed defaults when an empty file gets saved. That put my WT and PowerShell environments back to rights, and I was then able to get the corrected script to run to completion on that PC.

I’ll observe that if you’re going to edit settings.json in PowerShell on a Windows PC, it’s a good idea to have a backup at hand to replace that file. I’m learning that it’s kind of like working on the registry, where changes can have even more serious and dire side effects. Cheers!