winget-cli
winget-cli copied to clipboard
microsoft
Open log files or provide path as output
Description of the new feature / enhancement
As you know the Log path is a less than intuitive location. ;) %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
I had to create a CMD file in order to easily get at the LOG file when opening issues.
I would like a way to quickly and easily discover the LOG file I just created. So that I can attach in bugs and in email. Yeah, yeah, I know I can do it in my CMD file using Batch, but I cannot be alone in this desire.
Proposed technical implementation details
I propose 3 things that would make my life easier.
- if you pass in the --verbose-logs option, the output includes path to the file: Example:
winget list zoom --verbose-logs
Name Id Version
--------------------------
Zoom ZoomUMX 5.10.4 (5035)
Log: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\<logfile>
We can debate if the path should be before or after the results. If we do it before, the benefit is any crazy script looking at the output may still succeed.
- Same as above, but you need to ask for the path Example:
winget list zoom --verbose-logs --logfile-path
Name Id Version
--------------------------
Zoom ZoomUMX 5.10.4 (5035)
Log: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\<logfile>
We can debate if the path should be before or after the results. If we do it before, the benefit is any crazy script looking at the output may still succeed.
- We provide an --open option. Example:
winget list zoom --verbose-logs --open
In this case the command is executed and afterwards, the log file is launched in the default windows editor.
I am leaning towards option 1. What do you think?
I have long thought a winget logs command that just opened the folder in Explorer would be helpful. If we just print the log file path then you'd have to copy-paste it into an Explorer window, which is an extra step.
(So I like option 3 the best, but I'd rather it be a command than an option so I can use it regardless of whether I remembered to put the argument on the command I'm looking for logs about.)
I had previously suggested #2130 , but I think that a command like winget logs would satisfy the desire to have an easy way to open logs. I would also suggest that if putting the log as an output, we consider #1977 and either change the rendering based on the terminal, or always output the full path to the log file
I like the winget logs approach.
I also like the winget <command> <argument> --open-logs approach.
With an --open-logs argument, the former winget logs might not be necessary.
It might be possible to support winget --open-logs to give the best of both worlds without needing a new top level command.
I could certainly see value in winget install <package> --verbose-logs --open-logs
Of course, a user with verbose logs in their settings wouldn't need to add --verbose-logs, but many users likely don't have that configured.
@Trenly,
How would you feel about making the feature stable? I think this is a fantastic addition to WinGet 1.5.
@Trenly,
How would you feel about making the feature stable? I think this is a fantastic addition to WinGet 1.5.
I'd be happy to! The only thing I'm not sure of is how to integrate it into the PowerShell Modules and COM API, since it's a top-level argument (can be added to any command, including root command)
Awesome! I'm sure the team is more than happy to help :)
Merged into master :D