`winget list` truncation is not uniform

[ns-hsundararajan]

Relevant area(s)

WinGet CLI

Relevant command(s)

winget list

Brief description of your issue

I am deploying software to multiple laptops, and using winget list to track. However, the outputs are not consistent for the same software.

I am executing winget list > package_list.txt

Here is one example. On one laptop I see

Microsoft Photos                         MSIX\Microsoft.Windows.Photos_2026.1102… 2026.11020.2000…               

On another, I see

Microsoft Photos                          MSIX\Microsoft.Windows.Photos_2026.11020.… 2026.11020.2000…            

Why is that in the first host's output, it is truncated after 1102... but in the second host's output it is truncated after 11020... ?

Similarly, here's another example

Microsoft Engagement Framework           MSIX\Microsoft.Services.Store.Engagemen… 10.0.23012.0                   
Microsoft Engagement Framework            MSIX\Microsoft.Services.Store.Engagement_… 10.0.23012.0                

On some hosts, the truncation happens after Engagemen (without the t) but on other hosts it is truncated after Engagement (with the t)

Here is another

Dolby Digital Plus decoder for PC OEMs   MSIX\DolbyLaboratories.DolbyDigitalPlus… 1.2.588.0                      

vs

Dolby Digital Plus decoder for PC OEMs    MSIX\DolbyLaboratories.DolbyDigitalPlusDe… 1.2.588.0                   

winget list as it is has no option to not truncate when redirecting output to a file. I would atleast expect the truncation happens uniformly.

Steps to reproduce

It seems random, I do not know how to deterministically reproduce.

Expected behavior

The output of winget list is identical in all hosts where identical softwares are installed.

Actual behavior

In different hosts, the same software name/version/id gets truncated at different points.

Environment

winget --info
Windows Package Manager v1.28.220
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26200.8037
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.28.220.0

[florelis]

For automation, it is better to use either the COM API or the PowerShell module than trying to parse the CLI output.

[ns-hsundararajan]

For automation, it is better to use either the COM API or the PowerShell module than trying to parse the CLI output.

@florelis i would, except the powershell output doesn't give me all packages that the CLI gives me. (#6136) So I need the CLI output because it's more reliable and correct, but it is not consistent

[florelis]

I see. It seems one of the issues you see is that winget list can show when there are multiple versions of the same package installed but Get-WinGetPackage cannot. Is that the only discrepancy you see or are there more?

Regarding the truncation, the location where it happens depends on the width of the console (or 120 if there is no console) and also on the content of the whole table. An initial width is set based on what would be needed to not have any truncation in any row or column, then it iteratively trims the widest column until the table fits in the console. So, if there is any difference in the packages installed on each host, it may affect the truncation for everything.

(I know this doesn't solve anything for you, I'm just adding some information/context)

[ns-hsundararajan]

@florelis

winget list can show when there are multiple versions of the same package installed but Get-WinGetPackage cannot. Is that the only discrepancy you see or are there more?

At the moment that's the only / immediate discrepancy I am seeing. I wonder if there's a separate bug filed against powershell specifically for detecting multiple versions

the location where it happens depends on the width of the console (or 120 if there is no console)

Yes, I am redirecting to a file, so I expect (and am fine with) the 120 width

also on the content of the whole table
So, if there is any difference in the packages .... affect the truncation for everything

Ouch ! I can live with the truncation if the strings were truncated at the same place consistently, but the presence of a longer package in one host trimming the identical packages in both hosts to different levels makes it harder to programmatically process them :(

Thank you for the context nevertheless !