avoiding truncating search/list result

[itn3000]

Description of the new feature / enhancement

Currently, result of winget list and winget search is truncated for adjusting display size or 120 chars if output is redirected.
This causes the inconvenient which cannot be display full name,id,tags of apps which has long one(eg. Visual Studio family).
It cannot be avoided even if result is redirected to file because max width is currently hard coded to 120 in source if redirect.

So I'm glad if options which set max width or getting no truncated string is added(or output with another structured format like json,csv,xml?).

Proposed technical implementation details

No response

[sba923]

I'd like an option resulting in behavior similar to PowerShell's Format-Table -AutoSize i.e. don't truncate anything, which requires computing widths based on the widest value for each and every field.

See #2161

[jantari]

This would be solved by #1753

To use the functionality of PowerShells' Format-Table -AutoSize I would suggest using the winget PowerShell cmdlets and then just running the actual Format-Table -AutoSize cmdlet. I don't think this has to be re-implemented in the winget CLI. The winget CLI will never have feature parity with all of PowerShells' built-in filtering, sorting and formatting capabilities.

The only open issue here is that output is truncated to a width of 120 characters when redirected to a file. I don't see the reason for that, textfiles don't care about the length of the lines stored in them. But maybe there is a good reason.

[sba923]

Indeed, a change where the truncation is removed when output is redirected (to a file, to a pipe) would IMVHO be the best solution.

@denelon what do you think?

[denelon]

We're working on rich PowerShell objects currently, so I would also suggest focusing the attention on the new cmdlets at this time.

WinGet defaults to 120 columns if it cannot get the value from the "consoleInfo".
The top 50 lines of output are considered for formatting the table.

winget-cli/src/AppInstallerCLICore/TableOutput.h

Lines 13 to 30 in 741955e

	namespace AppInstaller::CLI::Execution
	{
	namespace details
	{
	// Gets the column width of the console.
	inline size_t GetConsoleWidth()
	{
	CONSOLE_SCREEN_BUFFER_INFO consoleInfo{};
	if (GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &consoleInfo))
	{
	return static_cast<size_t>(consoleInfo.dwSize.X);
	}
	else
	{
	return 120;
	}
	}
	}

[halr9000]

WinGet defaults to 120 columns if it cannot get the value from the "consoleInfo". The top 50 lines of output are considered for formatting the table.

I know that Bill Gates never said the apocryphal quote, but I can't help myself:

120 columns ought to be Enough for Anyone!
/s
:)

[g0t4]

What needs to be done to fix this? I am happy to help with the code. This is unbearable.

[denelon]

@g0t4 I think the PowerShell module helps in this case tremendously, but from a CLI perspective, I'd think about an argument and setting pair. Naming things is hard, but I could imagine "--no-truncate" & "--truncate" as arguments with a default setting of "truncate" that can be overridden via the CLI and an optional setting for "don't truncate" that can be overriddent via the CLI.

We could also make the "default" width a variable that consumes from an argument and settings.

Another option to consider is an "--output-width" with a value and corollary settings.

[g0t4]

@denelon thanks for the suggestion, I prefer the output of Get-WinGetPackage given I can customize that with my own formatting

[halr9000]

@denelon thanks for the suggestion, I prefer the output of Get-WinGetPackage given I can customize that with my own formatting

this is the (powershell) way

[sba923]

@denelon thanks for the suggestion, I prefer the output of Get-WinGetPackage given I can customize that with my own formatting

Indeed, that's going the right / PowerShell way.

But when you come from the winget CLI tool, discoverability is, er... far from obvious:

[Trenly]

[Policy] Area-Output

[Fred-IV]

"No one will ever need more than 640K ram" - Bill Gates, 1981

[dertuxmalwieder]

Actually, not Bill Gates.

[josesa-xx]

i don't have Get-WinGetPackage in Windows 10 22H2, where do I get it ?

[jantari]

@josesa-xx

Install-Module -Name Microsoft.WinGet.Client

https://www.powershellgallery.com/packages/Microsoft.WinGet.Client

[josesa-xx]

Thanks for the suggestion I was able to get a full list without truncation with command:

Get-WinGetPackage | Format-Table -AutoSize | Out-File -Width 500 -FilePath winget_packages_$env:COMPUTERNAME.txt

[kater-murr]

Thanks for the suggestion I was able to get a full list without truncation with command:

Get-WinGetPackage | Format-Table -AutoSize | Out-File -Width 500 -FilePath winget_packages_$env:COMPUTERNAME.txt

This doesn't work on my testing machine. (I get the same truncated output with max 120 chars.) Did you maybe change any settings or environment variables?

What I found is that the command

& winget list

formats the output to the maximal size of the console window. Up to 163 characters on my testing machine. So the omitted parts are obviously not just gone. But I can't find a way to catch all the output in a file or variable.

[sba923]

This works fine here, in PowerShell 7.4.3 running in Windows Terminal Preview 1.21.1772.0 with an intentionally low (53-char) console width. The resulting text file's lines are 211 characters wide.

[kater-murr]

This works fine here, in PowerShell 7.4.3

You are right. Thanks for the hint. It works in PowerShell 7.4.3, it doesn't in 5.1.19041.4648

Thanks to all of you.

[dertuxmalwieder]

I still wish that was right in PS, so it could be reliably used for scripting on other people's computers.

[Sebastian-Cerga]

Get-WinGetPackage | Format-Table -AutoSize (if terminal window is wide enough OR output to file using "| Out-File -Width 500 -FilePath winget_packages_$env:COMPUTERNAME.txt") are working fine on "PowerShell 7.5.0-preview.3".

Still wish this would have been default behaviour in "winget list"

[dertuxmalwieder]

M$

Writing lik€ thi$ do€$ not h€lp your cau$€, pal.

[Marvodor]

As it seems to be really difficult to just not truncate the piped output of "winget list", can we please change the constant 120 to 255 or 65535 or anything else not completely too small?

[Marvodor]

Install-Module -Name Microsoft.WinGet.Client

The most obvious difference to "winget list" is the usage of three ASCII-dots "..." instead of an Unicode-ellipsis "…". The output is truncated anyway and I have a bad feeling because I had to install third-party-software from a source flagged as being unsecure.

PS‌ get-host says I am using Powershell version 5.1.19041.4648 although all Windows updates have been installed.

[sba923]

PS‌ get-host says I am using Powershell version 5.1.19041.4648 although all Windows updates have been installed.

PowerShell 7 is not an "update to Windows PowerShell 5.1" but kind of a "different product" that installs side-by-side and is not part of Windows (yet 😝).

[Marvodor]

PowerShell 7 is not an "update to Windows PowerShell 5.1" but kind of a "different product" that installs side-by-side and is not part of Windows (yet 😝).

Thank you, my old cmd file finally works as expected :-)

echo y|pwsh -c "install-Module Microsoft.WinGet.Client"
pwsh -c "get-WinGetPackage | format-table -autosize | out-file -width 1000 -filepath $env:liste"
if errorlevel 1 winget list>%liste%

[mominshaikhdevs]

@g0t4 I think the PowerShell module helps in this case tremendously, but from a CLI perspective, I'd think about an argument and setting pair. Naming things is hard, but I could imagine "--no-truncate" & "--truncate" as arguments with a default setting of "truncate" that can be overridden via the CLI and an optional setting for "don't truncate" that can be overriddent via the CLI.

We could also make the "default" width a variable that consumes from an argument and settings.

Another option to consider is an "--output-width" with a value and corollary settings.

@denelon @Trenly, (adding #3071 too) whats the latest update on this?

[wykopx]

After 3 years since creation of this issue

the Name and the ID of installed apps are still truncated

winget list

There is a workaround to view full ID using this PowerShell command:

Get-WinGetPackage | Select Id

[mm6502]

It should allow output in json or something...

[jantari]

@mm6502 Get-WinGetPackage | ConvertTo-Json

[mm6502]

@jantari
That is not very helpful in my scenario. I need the user to provide a list of software he has installed on his machine. He won't be able to install random stuff (due to permissions and skills). But I can ask him to provide a file generated by:
> winget list --output-format json --output-file the_list.txt

[sba923]

@jantari
That is not very helpful in my scenario. I need the user to provide a list of software he has installed on his machine. He won't be able to install random stuff (due to permissions and skills).

But you're assuming winget is present on their machine?

[mm6502]

@jantari
You are looking for problems where there are not any. I know it is.

[josh-hemphill]

@sba923
But you're assuming winget is present on their machine?

I've been able to rely on winget being present on all new installs when I deploy systems, it's been shipping with windows for a while now... (And even Win Server 2025 seems will ship with it)

[jantari]

@mm

@jantari You are looking for problems where there are not any. I know it is.

Hey, that wasn't me 😅

But we're bringing up a good point - why isn't the PowerShell module also preinstalled just like winget itself is? Many issues like this one show that the old DOS CLI just doesn't work for people.

@josh-hemphill

(And even Win Server 2025 seems will ship with it)

Unfortunately, only with the "Desktop Experience" installation. See the announcement and this issue.

[AltitudeApps]

I just added a comment to the issue discussing the need for textual structured output, here: #1753

Most of it applies in this context, so I'll just paste most of what I typed over there:

I agree with the need for both JSON and CSV output, as well as simply providing arbitrarily wide text output which can be redirected to a file.

The original design philosophy of PowerShell included the ability to flexibly integrate other text-based command line tools seamlessly. Using PowerShell modules and .NET objects everywhere is NOT "the PowerShell way", it is just part of the PowerShell way.

A bespoke PowerShell module seems goofy when the winget CLI already does everything that I need it to do. Almost everything, that is. The winget CLI provides for all my needs, as long as I'm sitting in front of the console, watching what's printed after each command. I can widen my terminal and get full output. But try to redirect the perfectly good output to a file? Winget deliberately defeats me by truncating the strings, and now I discover that the project defies user requests to provide some sort of simple text output, which we could then pipe into whatever other tooling we might be needing to interact with.

Another scenario: sometimes I need to run winget in a cmd.exe session in a legacy console host. For instance, when I want to upgrade Windows Terminal and/or PowerShell 7.x itself. It makes things much less confusing when the items I'm upgrading aren't running at all.

It looks like one might be able to direct their attention to this portion of the code:

winget-cli/src/AppInstallerCLICore/TableOutput.h

Line 130 in 28a239c

size_t consoleWidth = GetConsoleWidth();