Holy Moly! I’ve been enjoying the workout involved in getting PowerToys “Command Not Found” (CNF) facility installed on my PCs and VMs.  My latest adventure has been dealing with what happens when the Command Not Found module is itself not found. It might not be recursive, but it is amusing. After numerous  futile tries to fix the PowerShell Profile or change its associated path, I simply uninstalled CNF, then re-installed it afresh. That’s how I learned a do-over fixes persistent CNF error.

Why a Do-Over Fixes Persistent CNF Error

Examine the intro graphic above. It asserts that the CNF module “was not loaded because no valid module file was found in any module directory.” A search did turn up a module with the matching name (using Voidtools Everything) but something apparently went wrong with the file transfer, because this error message popped up anyway. I can only conclude that means it was invalid (inoperative). That said, all the PS path info on this machine matched that on my other PCs, so I’m confident it was never the problem.

I’m pretty sure that’s why a do-over fixed things. When I uninstalled the munged version, all that stuff got deleted. When I installed afresh, the new copy of the module worked and the PS profile change did, too. As you can see in the next screencap it shows that the profile was loaded (top lines). Then I type “vim” to show that CNF intercepts this missing item and tells me where to go to find it. Problem solved!

The old “remove-replace” operation fixes baffling Windows errors. Here, you see profiles loading and CNF working after same.
[Click image to see full-sized view.]

There’s No School Like the Old School

In my three-plus decades of working with Windows I’ve seen my share of odd and interesting errors. Sometimes, things don’t work on the first try. But the uninstall-reinstall sequence — which I like to call the old remove-replace operation, hearkening back to my shade-tree mechanic days — will often fix otherwise mysterious and unexplainable errors or failures.

At least, it worked for me this time with the odd invalid module error for Command Not Found in PowerToys. A small triumph for common sense, here today in Windows World.

Last Thursday, January 11, I blogged about the new PowerToys Command Not Found (CNF) facility. This weekend I stumbled upon what I call an “interesting CNF side-effect.” I rattled off the “cls” (clear screen) command, but missed the last character and typed “cld” instead. The lead-in graphic shows what happened. Cool!

What IS the Interesting CNF Side-Effect?

When the CNF sees a string that doesn’t match uninstalled or already-known commands, it suggests “the most similar commands” as shown in the intro graphic. That’s a sure-fire indication that something went wrong on the data entry front. I’m amused that the “cls” command string — a closer match than the change directory, or cd, command — doesn’t come up in the suggested alternatives.

But hey! To me this behavior is a bonus above and beyond the entirely helpful impetus to let users enter commands they know they want to use, and bring them aboard through the CNF facility. In this case, it’s a nugatory command that doesn’t exist because it’s a typo.

I quickly learned to see this effusion of text as a clear sign that I goofed somehow. That’s what makes it useful to me. Hopefully, you will find it equally useful.

The Joys of PowerShell and WT Increase

Everywhere I look, I see plenty of evidence that the Windows Terminal and PowerShell teams are working hard to make these tools more friendly, powerful and useful. The integration of Copilot is something I’m just starting to dig into and appreciate in the same vein (but on steroids).

All I can say is “Keep up the good work, folks!” Their efforts are making my life more fun and more interesting. They’re also encouraging me to make more and better use of a terrific toolbox when working with Windows. I’m jazzed!

Wow! I got a great, unsolicited tip from Demitrius Nelon yesterday (he’s the winget team lead at MS, and a great communicator). It explains a way to grab the download for any package that winget can find. It came up in the context of updating the package named Microsoft.PowerShell, but it will work for any package by name. He informed me that if you run winget show, it will include an installer URL. I knew that. What I didn’t know and am jazzed to learn, is that you can CTRL-click the link and it will fire up your default browser and download it. That’s what “Winget Show URLs are live” means.

Because Winget Show URLs Are Live, Use Them!

This comes up in the context of PowerShell reasonably often for me, because I run PowerShell as my default shell inside Windows Terminal. Alas, when some new PowerShell updates pop up, winget can’t install them because their “install technology” changes. That’s because winget is inherently conservative when updating, and won’t make big changes on its own. Thus, for example, when an install technology change hits PowerShell, one must then download the new version from GitHub and run the installer to make the update.

Look near the bottom of the lead-in screengrab, which shows the output for “Winget show MIcrosoft.PowerShell.” It’s the section that starts with “Installer:” at left. 2 lines down the label reads “Installer Url” with the actual github download link to its right. If you hold the CTRL key down and click on that URL, download will commence.

This is about as handy as updates get when winget won’t do them for you automatically. Shoot! It makes a pretty good alternative to winget install <package-name>, too. Thanks, Demetrius: this tip makes a snazzy stocking stuffer. Happy holidays!