Category Archives: PowerShell

Bringing Neofetch Aboard via WinGet

I knew there had to be a way. I just couldn’t find it or figure it out on my own. The venerable old OS info command line tool Neofetch (best known to UNIX and Linux users) works at the Windows command line, too. But I struggled with Chocolatey and Scoop to get it installed without liking the results. This morning Eleven Forum user Lance1 posted a terrific WinGet-based install/update tool from Chris Titus with an understated title “You may find this handy.” Indeed I did — and I also successfully tried bringing Neofetch aboard via WinGet on my production PC. You can see it running in the lead-in screengrab.

What’s Behind Bringing Neofetch Aboard via WinGet?

Running the command from Lance1’s post — namely

iwr -useb https://christitus.com/win | iex

absolutely did the trick for me.

Here’s how Copilot breaks this command string down (all six numbered items are quoted verbatim therefrom):

  1. iwr: This is an alias for the Invoke-WebRequest cmdlet. It sends an HTTP request to a web server and retrieves the response.
  2. -useb: This parameter tells Invoke-WebRequest to automatically unblock the downloaded file, which is useful when downloading scripts from the internet.
  3. https://christitus.com/win: This is the URL of the file you’re downloading. In this case, it’s a script hosted on Chris Titus’s website.
  4. |: This is the pipeline operator, which passes the output of one cmdlet to another cmdlet.
  5. iex: This is an alias for the Invoke-Expression cmdlet. It runs a script or command that is passed to it as input.

In summary, says Copilot: “this command downloads a script from https://Christitus.com/win and then executes it immediately on your system.” It’s what pops up the partial console that includes a checkbox for Neofetch, like so:

And when I clicked on Install/upgrade selected in the console pop-up window, it showed the following output as it used WinGet to handle the Neofetch install:

I’m jazzed. I need to spend more time with this Chis Titus tool and see what ELSE it can do. Lance1 was certainly right in his low-key estimation of its utility. I’ve already found it handy, so to speak. Cheers!

Facebooklinkedin
Facebooklinkedin

WinTerm Multi-Line Paste Flag Is Helpful

Way to go, Windows Terminal (WinTerm) development team. I just accidentally hit Paste (Ctrl-V) inside that application, and it posted the warning you can see in the lead-in graphic. I saved myself unnecessary error messages — and the app saved itself from associated error handling — by warning me I was about to do something possibly stupid. Indeed I was, as you can see from the clipboard contents info in the screencap. Hence my considered judgement: the WinTerm multi-line paste flag is helpful.

Obviously, WinTerm Multi-Line Paste Flag Is Helpful

Shoot! Given how often, and in how many ways I use the paste buffer, there could be just about ANYTHING in there. That includes all kinds of text and even images. I use cut’n’paste all the time while writing, especially when updating older stories from Windows 10 to 11 coverage. I’ve done that dozens of times in the past couple of years for ComputerWorld, Tom’s Hardware and TechTarget. Plus, I often use cut’n’paste to drop screencaps into social media posts as I’m commenting on Windows news and observations. None of that stuff works in PowerShell, folks!

It’s a good thing when application designers and developers recognize human frailty, and take steps to protect users from themselves. It’s particularly good, IMO, when that user is me!

Windows Terminal Keeps Getting Better and Better

From its own self-update behavior, to various UI and Settings improvements, to PowerToys add-ins (Think: “Command Not Found”), Windows Terminal has just kept steadily improving over the past 2-3 years. The more I use it, the more I’ve come to like it. And now, with Copilot to assist me in writing PowerShell scripts, I’ve become better able to take advantage of that ever-increasing goodness. You should, too.

Facebooklinkedin
Facebooklinkedin

OhMyPosh Auto Update Hangover Fixed

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

New OhMyPosh Version Highlights Auto-Update

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

OMP Changes Update Handling

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

Identify Spurious Windows Reclaimables

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

Power Options Get Missing Plans

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

WinGet Discord Update End-Around

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

WinGet Updates PowerShell, Error Aside

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

Update and Check Windows Terminal Versions

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