Category Archives: PowerShell

Cool Tools, PowerShell, WED Blog, Windows 10, Windows 11

OhMyPosh Auto Update Hangover Fixed

Leave a comment

Here’s an interesting one. Indeed one can configure or enable the excellent OhMyPosh prompt tweaking tool  (aka OMP) to update itself. But there’s a trick involved in getting WinGet to recognize an update has occurred. I call it an “update hangover.” Apparently the local copy of the WinGet source list itself needs a reset before it catches up with what’s happened. (That list provides the basis from which it decides what’s fresh and what needs updating.) Let me explain — and show — how I got this OhMyPosh auto update hangover fixed.

Getting OhMyPosh Auto Update Hangover Fixed

Take a look at the screencap in the lead-in graphic. Before this sequence occurred, OMP told me as the PowerShell session started up that it was updating itself to version 24.18.1. You’ll notice that selfsame “Available” version according to WinGet upgrade output right at the head of that PowerShell command sequence.

Keep reading. Note that the output for oh-my-posh –version also reads 24.18.1. Thus, OMP is already upgraded and already current. But after I complete the valid remaining upgrade manually (for Microsoft.WindowsADK), another simple upgrade check shows that WinGet thinks OMP still needs that upgrade.

What to do? I try basic winget source reset — which attempts a reset for the winget and msstore sources — but the command output tells me the directive requires the –force option to work. So that’s what I try next:

winget source reset –name winget –force

As you can see when I do the next upgrade check after that, WinGet now reports “No installed package found matching input criteria.” That means it no longer sees OMP as a legit update target. Fixed!

Now, I wonder if Jan DeDobbeleer can figure out a way to reset the local list of packages for comparison to the WinGet source as part of his auto-update function. Probably not: knowing his thorough and deliberate approach to this package, he’d have done it already were that possible.

 

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

New OhMyPosh Version Highlights Auto-Update

Leave a comment

As the world returned to a more normal work rhythm yesterday, I found myself fielding various new software updates. Among them, a bump to OhMyPosh version 24.18.0. It wouldn’t work via WinGet because — as you can see in the lead-in graphic — it introduces a “newer version” for its “install technology.” Thus, this new OhMyPosh version highlights auto-update gotcha. I’d already used the oh-my-posh enable upgrade command to automate that process. A new install wipes out that directive.

If New OhMyPosh Version Highlights Auto-Update, Then What?

This got me looking at ways to embed the same information in the omp.json file that drives OhMyPosh configurations. Turns out when a reinstall happens, default configurations are rewritten from scratch. Thus, adding commands to

“auto_upgrade”: true,
“disable_notice”: true,

likewise got wiped from my chosen JanDeDobbelleer.omp.json config file as well. (Add them to the end of that file and you’ll need to drop the second comma, in fact.) What to do?

Turns out a custom config file is left alone when you have to shift from an older install technology to a newer one. Renaming the default config file, adding customizations, and referencing that new name in the invocation for OMP will do the trick. Way to learn, I guess!

Best Gets Better, After Sussing Out the Wrinkles

My fervent thanks to Jan DeDobbelleer, the OMP developer and chief steward. There’s seldom anything that goes off with OMP that isn’t addressed in his copious documentation and online interactions with other users. It sometimes takes a little while — about half an hour for this set-to, for example — but I have always been able to figure out and fix whatever gets hinky with OMP. That’s quite a testament to the tool and its builder. Thanks again for everything, Jan!

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

OMP Changes Update Handling

Leave a comment

I should have seen this one coming. Jan De Dobbeleer’s excellent Oh My Posh (OMP) prompt glyph handling (for PowerShell on Windows Terminal in my case) is going through lots of changes lately. Among those is an “upgrade” option in its configuration file. I’d seen prompts about it awhile back (September, perhaps?) but hadn’t take the time to investigate. But when OMP changes updated handling, I did so. Turns out it’s dead easy and I should’ve done it right away. Live and learn, right? The lead-in graphic shows how easy: a one-liner OMP instruction: oh-my-posh enable upgrade. Done!

Avoiding How OMP Changes Update Handling Brings Trouble

The next screencap shows the pickle I put myself in yesterday. The latest OMG update (v24.12.0) uses a different install technology from the previous version, so handling it via WinGet meant an uninstall/install manuever. You can see what happened when I did that.

After uninstalling OMP, the Terminal startup can’t initialize it.

After uninstalling OMP, Windows Terminal can’t execute its initialization (’cause there’s nothing to initialize). And when I install it, it won’t run in that Terminal window (or pane). It must be invoked. That’s why I opened a second terminal session (right-hand pane) so OMP would actually load and run. Simply enabling OMP to update itself via the aforementioned command is a heck of a lot easier, and far less disconcerting.

Now, I need to go through and do this on all of my Windows PCs with OMP installed (the vast majority, in fact). Again: I should’ve done it right away. Maybe that’s the moral of the story…

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

Identify Spurious Windows Reclaimables

Leave a comment

OK, then: thanks to some excellent detective work by ElevenForum stalwart @Bree, it looks like DISM can tell curious Windows users which packages are “stuck.” That is, you run the DISM command sequence: Analyze-Clean-Analyze, with a positive number of reclaimable packages still showing. (You can find all the details in my 11/2023 blog post on this topic.) This time around, I’ll show you how to list out the actual items that identify spurious Windows reclaimables. Warning: some PowerShell hacking is involved!

How-to: Identify Spurious Windows Reclaimables

@Bree shows the source for the data needed to identify these strange offenders. It’s based on analyzing data within a DISM generated text file. Here’s the specific command that creates that data:

DISM /ONLINE /GET-PACKAGES /FORMAT:TABLE > KB.txt

What this does is to inspect the current running Windows image (/online), grab all packages it finds with some related data (/get-packages),  and format it into a table (/format:table). That last bit (> KB.txt) redirects command output into that named file. The column headings in that output read: Package Identity, State, Release Type, and Install Time with vertical bars (‘|’) used to separate entries.

Bree’s analysis concurs with my own prior inspection of this same kind of output. We both agree that only lines with the strings “Staged” and “Feature Pack” in them point to spurious Windows packages. His analysis depends on sucking the output into a text file, converting to Excel format, sorting by State, and counting groups of lines to match the spurious reclaimable count to what’s reported by DISM /AnalyzeCompontentStore. Remember: those are packages that stay in the component store even after a DISM /cleanup-image operation has completed successfully. I simply write the output from the /Get-Packages DISM command to a file named KB.txt and filter its results.

Automating Analysis of KB.txt Contents

Next, my PowerShell script comes into play (such as it is, it’s pretty primitive). Unzip kbfilt.zip and then move kbfilt.ps1 to the directory where you created kb.txt (to run this file type .\kbfilt.ps1 inside an administrative PS Terminal window: screenshot follows later).

# Path to the input text file
$inputFilePath = "kb.txt"

# Path to the output text file
$outputFilePath = "kbfilt.txt"

# Read the file line by line and filter the lines
Get-Content $inputFilePath | ForEach-Object {
# Check if the line contains both "Staged" and "Feature Pack"
if ($_ -match "Staged" -and $_ -match "Feature Pack") {
# Output the line to the output file
$_ | Out-File -FilePath $outputFilePath -Append}}

# Confirm the script has finished
Write-Host "Lines w/ 'Staged' and 'Feature Pack' written to $outputFilePath"
Write-Host "Remember to delete kb.txt, kbfilt.txt before next use"

I used the -Append directive for Out-file which means the script appends text to the file and doesn’t over-write (“clobber” in PS-speak) other content. That’s why you’ll want to delete these files if you want to run the script again.

My Copilot+ PC (an Intel Aura Yoga Slim 7 model from Lenovo), running Windows 11 24H2 Build 26100.2134, has 2 spurious packages as shown here:

2 packages with LONG names (typical for Windows)
[Click image to view full-sized.]

This investigation is simply to show you which packages are stuck. You can get rid ofthem with DISM /Remove-Package. But if you do, they’ll most likely pop back up again after you install the next Cumulative Update (CU). Windows images are funny that way. But at least, now you can identify the packages involved.

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

Power Options Get Missing Plans

Leave a comment

I was just reading a Ghacks story about enabling the Ultimate Performance plan in Power Options. But when I fired up Control Panel > Power Options, I saw that Lenovo had endowed its killer ThinkPad P16 Gen 1 Mobile workstation with exactly one power plan — namely, Balanced. To make sure Power Options gets missing plans, I had to do a little research and some simple PowerShell command magic. Here goes…

Here’s How Power Options Get Missing Plans

The syntax for adding a Power Plan requires a specific powercfg command to add it to a system — namely

powercfg -duplicatescheme GUID

That makes knowing those GUID (globally unique identifiers) important, so you’ll find those values in the table in the lead-in graphic for all the well-known Windows 10 and 11 Power Plans.

Another handy powercfg command lets you choose the Power Plan you wish to run

powercfg -setactive GUID

To save you any contortions you might otherwise need to get those GUIDs from the lead-in screencap, here’s a list of text values. Cut’n’paste them with my blessing…

Balanced 381b4222-f694-41f0-9685-ff5bb260df2e
High Performance 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
Power Saver a1841308-3541-4fab-bc81-f71556f20b4a
Ultimate Performance 15c9c4f6-8a2b-4a3f-bfcd-6b8d6b8f7e5c

P16 Shows Two — and Only Two — Plans in Power Options

For some odd reason, the P16 Mobile Workstation only shows two Power Plans in Power Options (see screencap below). Of course given that it’s a MOBILE WORKSTATION I simply must run “Ultimate Peformance.” You see the results from that PC next with that peerless Power Plan selected. Basta!

A Mobile Workstation needs Ultimate Performance. Here ’tis!

If I add any plan other than Balanced, it knocks the other one (e.g. High Performance, Power Saver or Ultimate Performance) out of the collection. Indeed powercfg /list only shows the same two that appear in the Power Options screen (like the preceding screencap). Copilot says that’s probably owing to manufacturer overrides (likely), WU items (possible), registry settings (possible), or the presence of modern standby mode (possible).

I now know how to fire up any specific power plan I might want to use, so I’m not inclined to hare off after that range of possibilities. I’ll ask the reviews engineering team at Lenovo about this the next time we chat. If I learn anything useful, I’ll add it to this post. Stay tuned!

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

WinGet Discord Update End-Around

3 Comments

I absolutely love Microsoft’s built-in package manager WinGet. But occasionally things happen when updating application that it can’t (or won’t) handle. As you can see in the lead-in graphic, it cheerfully discloses in red that Discord “…cannot be upgraded using winget.” Indeed, its own built-in update facility did nothing to get me to version 1.0.9165. Thus, my only shot at a WinGet Discord update end-around was the tried-and-true uninstall-reinstall maneuver. That worked, as you can see…

Why Use a WinGet Discord Update End-Around?

Short answer: because it worked. Apparently, it’s uninstaller is smart enough to leave user account information alone. Even though I uninstalled the old version and then installed the new one, it carried over anyway. I’d been worried I’d have to set accounts back up, but no. Everything came up as it should’ve even after an “out-with-the-old, in-with-the-new” operation had completed.

I’m counting myself lucky in this case. There are plenty of other applications that don’t ask if you want to keep personal, account and config info. Then they cheerfully wipe all that stuff out as part of the uninstall process. That makes getting back to where one started a little more time-consuming, especially when a reinstall requires account, password, and possibly even other information to complete.

What’s with Discord’s Pinned Status Anyway?

Notice my attempts to unpin Discord reported “There is no pin for package Discord” (line 7 in the intro graphic). In the past, WinGet has often reported it can’t update Discord because the app is pinned. That’s an experimental feature in WinGet that prevents ordinary syntax for updates from working on certain apps.

Contrary to expectations, though, Discord wasn’t pinned. Yet WinGet couldn’t update it, either. Because the built-in updater didn’t do anything when I tried it (right-click on the notification area icon, then select “Check for updates…” in the resulting pop-up menu), I didn’t have a lot of other options. Thus, I’m grateful that the remove-replace approach did the trick. As you can see from the name of the package downloaded, I did wind up with version 1.0.9165. That’s just what I wanted.

Good thing one can sometimes get lucky here in Windows-World. Glad to have this behind me with no apparent ill effects.

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

WinGet Updates PowerShell, Error Aside

Leave a comment

I have to chuckle. There’s a new PowerShell 7.4.4 out. I just used WinGet to update my production PC and it applied the update package. But when it got the end of the update, it reported “Installation abandoned” and ended the WinGet update session. Because 7.4.4 came when I closed, then re-opened, Windows Terminal it looks like WinGet updates PowerShell, error aside. You can see the sequence in the lead-in graphic.

WinGet Updates PowerShell, Error Aside

Notice that a “Cancelled” item shows up below the “Installation abandoned” notification. I’m guessing this last item refers to jumping out of the WinGet update sequence, because you see a normal command line prompt (spiffed up, thanks to Oh-My-Posh).

And sure enough, running WinGet upgrade –all –include-unknown finishes up the remaining items that appeared below PowerShell in the update list. In the next screencap I show a two-pane Windows Terminal session. On the left, you see the sequence of update packages installed; on the right, you see the PS Version is now 7.4.4.

To the left you see WinGet at work; to the right a newly-opened PS session says it’s v7.4.4. [Click image for full-sized view.]

One more thing: the final item in the upgrade sequence on the X1 Extreme was Winget itself (which appears as Microsoft.AppInstaller inside the upgrade list). At its conclusion, WinGet closes things out a bit more reasonably. It says:

Successfully installed. Restart the application to complete the upgrade.

Cancelled

I think that confirms my suspicion that the cancelled item refers to the WinGet session itself. It even throws a couple of Ctrl-C (^C) characters to make sure things get closed out. Here’s a screencap:

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

Update and Check Windows Terminal Versions

Leave a comment

When I checked over the PC fleet this morning WinGet let me know an  update for Windows Terminal was pending. It would take the program from version 1.20.11381.0 to 1.20.11781.0. Easy-peasey. But once is was done, I asked myself: what’s the best way to check that the new version is running. Thus, I found myself digging into how to update and check Windows Terminal versions. The lead-in graphic, in fact, shows two ways to version-check, captured from the colorful Lenovo Yoga Slim 7x Copilot+ PC.

For the record those two checks are:

1. Winget list Microsoft.WindowsTerminal shows the current installed version on the PC.
2. Click the down-caret in the WinTerm title bar, then click “About” from the pop-up menu to get the “About” mini-window atop the Windows Terminal application window.

How-to: Update and Check Windows Terminal Versions

The update part is easy using the general WinGet upgrade –all –include-unknown command. But if you want to target WinTerm explicitly, Winget upgrade Microsoft.WindowsTerminal will also work.

One thing to remember, as you’ll see in the next screencap: once you’ve updated Windows Terminal, you need to close the current session, then open a new one. Why? Because the process that’s running the old version won’t quit, and a new process to run the new version won’t take over, until you’ve done the “out with the old, in with the new” routine that this accomplishes. Good stuff!

Update and Check Windows Terminal Versions.ps-details

One more cool little detail: as soon as WinGet updates WinTerm, it bails back out to the command line. That’s so you can close/re-open your session and keep going…

Just another routine day here in Windows-World. I really enjoy working at the command line a LOT more, now that I’ve learned how to jazz things up and make best use of WinGet to keep them current.

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

Font Handling Works Through Settings

Leave a comment

OK, then: In the wake of the clean install on the Lenovo ThinkPad P16 Mobile Workstatation, I’ve been reworking some of my runtime stuff. Customizing Windows Terminal comes under that heading, near the top of my priorities. To take proper advantage of OhMyPosh, I have to add a so-called Nerd Font to that PC’s collection. Turns out this is way easy in Windows 11 because font handling works through Settings in that OS. Let me show you!

How Font Handling Works Through Settings

Once upon a time installing fonts in Windows meant visiting the C:\Windows\Fonts directory and dropping the various .ttf (typeface) files there. Then Windows could add them to its collection and display them in a variety of forms in the Control Panel element named Fonts.

And indeed, the Fonts CPL is still alive and well. But if you visit Settings > Personalization > Fonts you see the add fonts window there, with its “Drag and drop to install” instruction. Arguably this is exactly the same at using Control Panel > Fonts. But IMO it’s less work and more fun to use. At least it worked quite well for me.

What Came Out of My Visit to Fonts

Thanks to all the files in my personal account folders and their auto-backup to OneDrive, when I set up a new PC with the same MSA, it inherits all that stuff. So as soon as I visited Nerd Fonts, downloaded CakaydiaCove NF, and installed OhMyPosh on the P16, this is what Windows Terminal looks like (it’s using Jan De Dobbeleer’s eponymous theme named “JanDeDobbeleer” in its config file).

Font Handling Works Through Settings.winfetch

Windows Terminal showing winfetch and OhMyPosh at work, overlaid atop the Nerd Fonts download page. [Click image for full-size view.]

FWIW, I use the various Caskaydia Cove NF (Nerd Font) variants in Windows Terminal because they look great with OhMyPosh. But it’s both worthwhile and fun to poke around that collection to find something that you like and looks as good or better.

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

WinGet Source Hiccup Self-Repair

Leave a comment

I saw a new WinGet error message yesterday. In attempting a “blanket update” PowerShell showed a “Failed when opening source(s)…” error instead (see intro graphic above). That same error also suggested its own fix via WinGet source reset. I didn’t read carefully enough to see that the –force option was also required. But my next upgrade attempt succeeded anyway. There was apparently a WinGet Source hiccup self-repair at work. What happened?

OK, Why Did WinGet Source Hiccup Self-Repair?

I can only speculate that there was a transient communications glitch between my test PC and the URLs associated with the Microsoft Store and WinGet itself. To me, this dual drop most likely indicates an interruption of service at the ISP level. Both domains have vastly different IP addresses so it’s unlikely to have been something at their end. Hence my best guess that something affected the lookups from my end through my ISP,  Spectrum.com.

It’s amusing that I discovered this hiccup simply by entering another command (albeit an incorrect one). Upon re-entering the original blanket update:

winget upgrade –all — include-unknown

Everything went through as expected on the second try. Through well-cultivated habits, in fact, my first impulse with Windows when things don’t work as expected is simply to try again and see what happens. In this fragile world of ours (including Windows-World) what doesn’t work at first often succeeds on a subsequent attempt.

Had it turned out otherwise, I’d be showing a different screencap, and telling a different story. This time, second try was the charm!

Facebooklinkedin
Facebooklinkedin