Winget-cli: Output can't be used with Powershell

Created on 19 May 2020  Â·  9Comments  Â·  Source: microsoft/winget-cli

Brief description of your issue

winget.exe show | select 'Name'

Returns blank results. It looks like the output for winget isn't consistent with Powershell, which is the default shell in Windows.

Expected behavior

I should be able to start powershell via Win X and use winget.

Actual behavior

winget outputs unstructured data.

Environment

```Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19613.1005
Package: Microsoft.DesktopAppInstaller v1.0.41331.0

Links:
Privacy Statement: https://aka.ms/winget-privacy
License agreement: https://aka.ms/winget-license
3rd Party Notices: https://aka.ms/winget-3rdPartyNotice
Homepage: https://aka.ms/winget
```

Issue-Question

Most helpful comment

Rolling out a new tool in 2020 as an exe instead of, or at least, without a set of native PowerShell Commands seems, well, surprising. But I also feel like this happened with Project Honolulu, too, where the project team completely missed the desires of the target audience on the first release.

All 9 comments

That is to be expected and cannot be solved.

I think what you're really asking for is perhaps a -j switch (or similar) that causes winget to output structured data in JSON etc. then you can winget.exe show -j | convertfrom-json | select name

Is the intention that users launch cmd to run winget?

On Tue, 19 May 2020, 19:23 jantari, notifications@github.com wrote:

That is to be expected and cannot be solved.

I think what you're really asking for is perhaps a -j switch (or similar)
that causes winget to output structured data in JSON etc. then you can winget.exe
show -j | convertfrom-json | select name

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/winget-cli/issues/196#issuecomment-630997415,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABKEMVV6DI6UKOYR2MRNDTRSLFCNANCNFSM4NFHLT2Q
.

Rolling out a new tool in 2020 as an exe instead of, or at least, without a set of native PowerShell Commands seems, well, surprising. But I also feel like this happened with Project Honolulu, too, where the project team completely missed the desires of the target audience on the first release.

Created https://github.com/microsoft/winget-cli/issues/221 for native PowerShell cmdlets.

Definitely provide json output support. I'm done with parsing standard output.

It looks like Issue #184 covers JSON output.

It looks like two features were created to address this concern. @mikemaccana if you believe they don't address this Issue please create a new one. #184 #221

184 and #221 doesn't address the concern as windows commands should output structured data by default. winget.exe show | select 'Name' won't work. It should work.

@denelon: powershell is the default terminal for windows. winget should support Windows defaults, and not need extra winget-specific steps like outputting a different format and then converting from it.

Additionally - and it feels odd having to say this to a Microsoft employee - outputting native powershell would allow people who want CSV, JSON, Excel or any other format to be supported, allow us to format the output how we want, or do all the normal things one can do with a modern Windows command line app

@denelon: if the winget team doesn't want to support Windows' standard shell, then why?

@denelon: if the winget team doesn't want to support Windows' standard shell, then why?

One possible reason is that PowerShell is not in WinPE (by default) and also not in Windows Server Nano. It would be nice for a package manager to work on Windows Nano.

Also, PowerShell cmdlets must be written in PowerShell or C#. They are going to be slower than this app, which is native C++.

But that is only a guess, I don't know their reasons. I know there's a place for non-PowerShell cli-tools on Windows, but I feel as though there needs to be a special DOCUMENTED section explaining why any given new tooling is NOT PowerShell based. Otherwise we're just going to end up with a mess.

Was this page helpful?
0 / 5 - 0 ratings