Off topic: How does WingetUI parse winget CLI output

[MichaelBrunn3r]

Hi, I'm trying to parse the CLI output of winget list in a Rust project, but winget trims the ID colum. I was looking at similar projects (like this one) to see how they do it successfully.

I found the relevant line in the source code:

p = subprocess.Popen([self.EXECUTABLE, "list", "--accept-source-agreements"], stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE, cwd=os.getcwd(), env=os.environ.copy(), shell=True)

However, calling this code in a Python script does not work. The output is still trimmed:

import subprocess, os

p = subprocess.Popen(["winget.exe", "list", "--accept-source-agreements"], stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE, cwd=os.getcwd(), env=os.environ.copy(), shell=True)
while p.poll() is None:
    line: str = str(p.stdout.readline().strip(), "utf-8", errors="ignore")
    print(line)

> python .\test.py
Name                                 Id                                   Version                 Available            Source
------------------------------------------------------------------------------------------------------------------------------
Visual Studio Build Tools 2022       Microsoft.VisualStudio.2022.BuildTo… 17.8.5                                       winget

This might be off topic, but I wondered if someone could help me understand how this project avoids the trimmed columns. Any help would be greatly appreciated

[marticliment]

Yes, this is an unavoidable bug with Winget. WingetUI also has this issue. Certain winget packages are trimmed.

You may want to take a look at Winget's PowerShell Modules

[MichaelBrunn3r]

Thanks, its good to know I'm not the only one with that problem :D

[ptlambert]

@MichaelBrunn3r MichaelBrunn3r

I found the relevant line in the source code:

p = subprocess.Popen([self.EXECUTABLE, "list", "--accept-source-agreements"], stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE, cwd=os.getcwd(), env=os.environ.copy(), shell=True)

@marticliment

https://docs.python.org/3.8/library/subprocess.html#subprocess.Popen

The shell argument (which defaults to False) specifies whether to use the shell as the program to execute. If shell is True, it is recommended to pass args as a string rather than as a sequence.

[...]

On Windows with shell=True, the COMSPEC environment variable specifies the default shell. The only time you need to specify shell=True on Windows is when the command you wish to execute is built into the shell (e.g. dir or copy). You do not need shell=True to run a batch file or console-based executable.

So winget.exe is definitely a console-based executable (albeit a strange one -- I can't for the life of me launch it correctly from within a .bat or .cmd file in Windows 10). If we tell Python to just launch it directly (i.e. without asking Windows cmd.exe to do that), then Python should still be able to grab stdout and stderr, no? And cmd.exe executing in a (hidden) default window size of 120 x 30 characters seems to be the root cause of the Id column being truncated, no? In any case, it seems to be proper form to use shell=False for this call to subprocess.Popen, since winget.exe is indeed not built into the shell...

(Yes I am just spitballing here, unfortunately I don't have Python setup in my development VM yet, since I was planning to use WingetUI to build out that VM...)

[marticliment]

With shell=false it does not work under certain scenarios

[ptlambert]

OK... but does shell=False fix the issue with truncated Id strings?

[marticliment]

no, it does not. and when setting a custom size virtual console the issue still appears

[brainz80]

Would it perhaps be simpler to use the Powershell module Microsoft.WinGet.Client ?

[marticliment]

Currently, UniGetUI uses the WinGet COM APIs, but there was a brief period where the powershell module was used to parse packages, instead of parsing the raw CLI output.