Category Archives: PowerShell

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

WingetUI Announces UnigetUI Name Change

Leave a comment

Though you can use it nicely with the Windows Package Manager, aka WinGet, WingetUI also works with other package managers. As you can see on its GitHub page, WingetUI also works with Scoop, Chocolatey, Pip, Npm, .NET Tool and the PowerShell Gallery. That’s a whole heap of package managers, and helps to explain why WingetUI announces UnigetUI name change in the app right now (see the lead-in graphic for same).

How WingetUI Announces UnigetUI Name Change

When I fired up WingetUI yesterday — for the first time in a couple of weeks, I cheerfully confess — the lead-in graphic popped up on my upstairs Windows 11 test PC (Asrock B550 mobo, Ryzen 5800 CPU, 64 GB RAM, Nvidia 1070TX GPU, etc.). In that little explainer, Marti Climent makes it clear that while WingetUI was initially designed to work only with Winget, it now covers numerous other package managers as well. Hence, the name change.

Of those other package managers, I’ve messed with Scoop and Chocolately. I’ve also turned to PowerShell Gallery on many occasions (though I’d call it a package repository more than a package manager, even though WingetUI/UnigetUI has worked with it for some while now).

WinGet CLI vs. WingetUI/UnigetUI

When I first discovered WingetUI I found it compelling and interesting because I was still learning the intricacies of WinGet commands and their sometimes convoluted syntax. But these days, I’m pretty darn comfortable with WinGet. Thus, I don’t find myself using WingetUI as much as I once did. Nevertheless, it’s a worthwhile tool that’s worth getting to know.

Indeed, I wrote a story about WingetUI for TekkiGurus last August (part of a 4-part Winget series). If you’re curious to learn more about either or both of these topics (Winget and WingetUI/UnigetUI) be sure to check them out. [Note: you’ll find links to the other 3 elements of the WinGet series if you visit the WingetUI story linked above.] Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 10, Windows Update

KB50001716 Is Puzzling

Leave a comment

OK, then. I was reading Martin Brinkmann’s post to gHacks this morning. It’s entitled “Microsoft’s sneaky KB5001716 Windows 10 update pushes Windows 11.” I don’t think my production PC qualifies, because its Intel SkyLake i7-6700 falls outside the range of supported CPUs. So I went looking for it, and learned some useful things. Let me share them with you…

Why KB50001716 Is Puzzling

First off I went to look at WU Update History to see if KB5001716 was present (or absent). I quickly realized that reading the whole WU history was more than a little taxing on a machine that’s been running Windows 10 since 2016.

So I turned to PowerShell where some operating on the Get-WUHistory command seemed like a good idea. When I figured out my Update History had 528 entries, that idea seemed even better. You can view the update history by creating a variable named $history, like so

$history = Get-WUHistory -last 1000

This grabs up to the last 1000 entries in the history records and assigns them to the variable $history. If you look at that output it’s kind of hard to ingest from Windows Terminal. It makes more visual sense if you look at it this way:

$history | sort date -desc | Format-Table Date,KB,@{l=’Category’;e={[string]$_.Categories[0].Name}},Title

[Note the preceding lines are a single PowerShell command string. If you want to try it, cut’n’paste into a text editor and make sure it’s a “one liner” before pasting into PowerShell. This produces output that looks like this:

KB50001716 Is Puzzling.table-output

Table format is more readable, but still too much to take in.
[Click image for full-size view.]

So I changed up the command string to write it to a file. That required appending the following string:

> i7wuhist.txt

The > symbol redirects the output, and the filename resides in folder context in which PS runs. Working with a file I was able to figure out the following:

1. I had no instances of KB5001716 in there anywhere
2. There were a total of 528 entries in that file.

I also concluded that my PC’s failure to meet Windows 11 hardware requirements probably meant that the upgrade offer (and indeed KB5001716 itself) were not forthcoming. Good to know, and I learned some interesting stuff along the way.

Facebooklinkedin
Facebooklinkedin
Cool Tools, PowerShell, Recent Activity, WED Blog

WingetUI Throws Bogus Update Notification

2 Comments

Alas, all tools have their little quirks. I’ve noticed recently that WingetUI is telling me to update CredentialManager (CM) from version 2.0 to version 2.0.0. They’re the same thing! Even more interesting when I tried running the Update-Module cmdlet manually, it told me CM wasn’t even installed on the target PC. So I used Install-Module to get it installed. You can see what happened next when I re-ran WingetUI in the lead-in graphic. Sigh.

Why Say: WingetUI Throws Bogus Update Notification?

What else should I say when WingetUI tells me to update something that’s not installed? And then, once installed it finds version mismatch from a “2.0” label from the developer versus aninternal Winget “2.0.0” label? Sigh again. I remember this kind of thing happening from time to time as I ran the old Software Update Monitor (SUMo), now out of action.

Look what happens when I click my way into “Package details” for CredentialManager inside WinGetUI and then click the update button for that package:

WingetUI Throws Bogus Update Notification.no update found

When it actually goes to look, it finds no update.

My best guess is there’s something in the CM manifest in the PS Gallery that’s presenting the version number as 2.0, and something going on with Winget that changes the value to 2.0.0. And indeed, if I look at get-installedmodule data again it shows the CM version number as 2.0. I’m hoping Demitrius Nelon and the winget team will check this out, and share their findings. Also filing a bug report via GitHub at the WingetUI pages.

Should be interesting to see what kind of response comes up. Cheers!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 10, Windows 11

CNF Conundrum Gets Some Love

Leave a comment

OK, then. I’ve been trying to figure out why, on some of my test PCs, I get an error message when PowerShell loads my profile and tries to import the PowerToys WingetCommandNotFound (CNF) module. You can see that error message in the lead-in graphic above (from my ThinkPad P16 Mobile workstation). Thanks to some fiddling around, this CNF conundrum gets some love — finally!

I haven’t figured out how to fix the problem properly just yet. But for the nonce, if I go into PowerToys, visit CNF, uninstall and then resinstall same, it returns to work. This happens every time I open a fresh PowerShell session, so it’s at least mildly bothersome. But I’m starting to make progress on figuring things out.

How CNF Conundrum Gets Some Love

The error message keeps changing on me as I add things to the folder where the profile resides — namely %user%\documents\PowerShell. First, it complains about not being able  to find the module itself. I copy it into that folder. Then it complains about a .DLL. I copy that, too. Finally, it complains about an error handler not being able to field a thrown exception.

It’s not fixed yet, but I now know that this issue comes from my PowerShell modules path set-up. Something is wonky between those search paths (there’s one for the system, and one for my login account) and PowerToys. This happens for one of my Microsoft Accounts (MSAs)  every time I use it to log into Windows, because this information is shared across those instances through OneDrive.

What’s Next?

I’ve got to research how I should be setting things up in the OneDrive environment to get PowerShell and PowerToys to get along with each other properly. I’ll be contacting the WinGet crew (Demitrius Nelon’s team at MS) to request additional info and guidance. That’s because my online searches have only clued me into what’s going on, but not how to fix it properly.

Stay tuned: I’ll keep this one up-to-date. And I’ll probably post again, when a resolution is formulated. This just in: OneDrive is reporting multiple copies of the PS profile in its file store. Could this be related? I have to think so. Again: stay tuned…

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Updates, WED Blog

PS Update Orphans PowerToys CNF

Leave a comment

Here’s an interesting one. I’ve noticed recently that when PowerShell gets an update, the next time it launches PowerToys “Command Not Found” (CNF) drops an error message. Hence this post’s title: PS Update Orphans PowerToys CNF.

You can see how this story starts in the lead-in graphic. It shows the error message that CNF.psd1 did not load “because no valid file was found in any module directory.” Seems like an impasse, don’t it?

NOTE Added February 15: It’s the profile not the PowerShell!!! The following observations are correct — the profile and the reference to CNF are indeed mismatched — but it’s NOT PowerShell’s fault. It’s because I’m backing up my profile stuff in OneDrive and the location in the profile is incorrect. Uinstall/reinstall fixes that issue until the next time OneDrive replaces the (correct) local profile copy with the (incorrect) cloud-based one. Sigh. I’ll write about this on Monday, Feb 19, after I’ve had time to figure all the angles!

PS Update Orphans PowerToys CNF Easily Fixed

I superimposed the CNF panel from PowerToys Settings for a reason, though. Even though its status messages and detections all show green, it turns out the real problem is that PowerShell itself can’t find the CNF module.

Here’s the easy fix. Uninstall CNF (click the Uninstall button at center right). Then it changes to an Install button. Now, click that and CNF gets reinstalled. Now, the next time you open PowerShell everything is copacetic, with CNF back at work, as shown in response to my now-standard “vim” test string:

PS Update Orphans PowerToys CNF.retry

After uninstall/reinstall CNF in PowerToys, close and then re-open PowerShell. [Click image for full-size view.]

Sometimes, when certain little things get you, other little things can set them back to rights. In this particular case, that’s how I’d generally describe the path to an error-free PowerShell startup after update, with a working PowerToys CNF as well. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog

New WT 1.19.10292 Solves Self-Update

Leave a comment

Life is always interesting for programmers when they have to update the code that’s running the update. This gets even more interesting for updates to Windows Terminal (WT) and PowerShell, running inside — you guessed it — WT and PowerShell (PS). Right now, a new WT 1.19.10292 solves self-update issues that remain present for PS. You can see the proud evidence in the lead-in graphic, which concludes a WT upgrade with “Successfully installed. Restart the application to complete the upgrade.” PS, on the other hand, still says “Cancelled” at the end of a self-upgrade, even though a restart reveals the newly-upgraded version at work.

How New WT 1.19.10292 Solves Self-Update

Windows users are actually much more familiar with this self-mod situation than they may think. Indeed, the reason why Windows must reboot after CUs and during OS install and upgrade, is so an updater or installer can work on files totherwise in active use RIGHT NOW if they weren’t suspended (if only temporarily).

In essence, this is what restarting WT/PS does. It terminates running processes for the code to be updated. Then they can be altered or replaced before the next set of new processes starts back up. I’m glad to see the WT team take such a steady and time-worn approach to updating Windows Terminal itself. It’s what makes most sense!

When I was learning to program back in the late 70s and early 80s one of my first and hardest-learned lessons was “Don’t step on your own toes” (write code that changesitself in unwanted or unplanned ways). That way lies madness. Glad to see those old lessons still apply, even for WT and PS.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, WED Blog

Do-Over Fixes Persistent CNF Error

Leave a comment

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.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, WED Blog

Interesting CNF Side-Effect

Leave a comment

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!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

Bringing Up PowerToys Command Not Found

Leave a comment

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).

Bringing Up PowerToys Command Not Found.winget-client

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:Bringing Up PowerToys Command Not Found.vimcheck

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!

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, WED Blog

Winget Show URLs Are Live

1 Comment

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!

Facebooklinkedin
Facebooklinkedin