Here’s something new in my personal experience. I ran Winget on one of my Dev Channel test PCs this morning. The latest version of PowerShell came up as an upgrade option. So I exercised it, and indeed the PowerShell version incremented from 7.2.6 to 7.2.7. Hence my claim that now, Winget updates PowerShell 7.2.7. You can see the process underway in the lead-in graphic for this story.

What Happens When Winget Updates PowerShell 7.2.7?

Things get a little weird along the way. Notice that after Winget starts the package install for PowerShell, it shows a “Cancelled” notification at the lower left corner of the Terminal session window. At the same time, the PowerShell installer (small pane at lower right) reports ongoing progress in removing the old version, then installing and configuring the new version.

When the progress bar goes all the way to the right, it simply disappears with no further communication from the installer. On a whim, I closed the open Terminal session window. When I opened a fresh one, here’s what I saw:

Once the progress bar completes, the installer goes silent. But if you close the open Terminal session, then open a new one, you’ll see it’s indeed been updated to 7.2.7.

I’m not sure how it’s supposed to behave because I’ve never seen winget upgrade PowerShell before. Normally, a full installer window opens with the masked PowerShell avatar (see below). Then, one steps through the typical standalone installation sequence. This time, with PowerShell running things it worked differently. A bit disconcertingly, too. But it’s installed now and works as expected. So I guess, all’s well that ends well. Cheers!

I guess I’ll miss the avatar going forward, but I do appreciate the convenience of upgrading inside PowerShell.

WinFetch is a windows-focused knock-off of another well-known shell tool named NeoFetch. Each is written to show useful and informative data about systems from within a command-line shell environment. NeoFetch is built atop bash; WinFetch atop PowerShell. IMO, that makes WinFetch more suited for use with Powershell. I’ve been working with WinFetch a lot lately, learning how to use it to help me see what I’m doing with Windows Terminal and PowerShell customizations. Indeed, it’s pretty helpful. But I’ve also been learning some lessons the hard way as I go. Let me explain…

Why Working with WinFetch Takes Some Effort

The documentation on WinFetch is kind of sparse. In fact, I’m starting to think I should spend my time reading the NeoFetch stuff, because it may shed more light on the inner workings of WinFetch. Straight from its GitHub home, there’s precious little info available about its details and settings. Sigh.

So far, the lessons I’ve learned the hard way include:
1. You must save the config.ps1 file that governs WinFetch behavior for its changes to take effect.
2. Sometimes, a reboot is required, above and beyond a simple save. I can’t tell why, but I found myself stuck a couple of times on this hump. If you make a change, save the config file and it has no impact on the WinFetch output, try a reboot. It may do the trick.
3. Customizing the WinFetch config is totally a trial-and-error exercise. Be prepared to spend lots of time tweaking and checking, then repeating ad infinitum. Sigh again.

Customizing for Winget Package Mgr

It took me a while — including plenty of the aforementioned trial and error, but I got WinFetch to look at and report on Winget packages. Here’s the syntax, straight from the config.ps1 file that makes WinFetch work:

$CustomPkgs = @(“winget”)
function info_pkg_winget {
return ((winget list | measure-object).count)
}

What you’re doing is telling winget to list all the packages it knows about, then piping that input into the measure-object cmdlet. Using its count attribute you simply show the overall package count. Sublime!