Colorize vswhere output #244
Conversation
Fails in PowerShell if you do something like `[xml](vswhere -format xml)` if color is enabled, so had to add -color switch. Not ideal since it otherwise disables color when piped, but still easier to read if colorized explicitly.
|
Colorizing the output is something I've been wanting to do for a while, and since I did it with the Go binding's test app I decided to take a crack at it now.
Initially color was enabled by default if stdout was to a terminal and the terminal supported VT100 sequences (which the conhost does in Windows 7 and newer). This works even when output is piped since stdout is no longer to a terminal, and is common in colorized console apps. Unfortunately, this fails in PowerShell like so: $instances = [xml](vswhere -format xml -utf8)The output is not piped, so the escape sequences are present in the output, which are not valid XML. As such, I added the Maybe someday we bump the major version to 3 and enable colors by default as well as UTF8 output, since that would've been a breaking change as well but probably something we should've done originally when JSON was added. The colors come from Visual Studio Code's Dark+ theme and should be suitable for the vast majority of terminals, which are generally dark. |
|
Windows PowerShell i.e. powershell.exe defaults to a blue background, but these colors are still quite legible:
|
|
Per offline discussion, going back to color by default but with a The integration tests that run in a Docker container make heavy use of this accelerator so we'll have a better sense for whether it's an issue in an isolated environment. |
heaths
changed the title
|
There's one "problem" I want to try to sort out first. Doesn't hurt anything, but not fantastic. Seems I need to write and flush to stdout at least once before color attributes take effect. You don't notice it with JSON because of the Perhaps @DHowett has some idea how to resolve the issue. I'm anxious about writing and clearing a single block character because of how that how that might affect output but, then again, that's only when stdout isn't redirected and I'm writing directly to the terminal buffer. |
Could simply call Initialize wherever it needs to be called, but would rather be explicit.
* Update docker image (#240) * Update microbuild pool to VS2019 * Use correct pool name * Update docker images * Colorize vswhere output (#244) * Refactor formatters to consolidate arguments * Colorize output by default unless piped * Opt into color and add tests Fails in PowerShell if you do something like `[xml](vswhere -format xml)` if color is enabled, so had to add -color switch. Not ideal since it otherwise disables color when piped, but still easier to read if colorized explicitly. * Enable colors by default, add -nocolor switch * Resolve PR feedback * Ensure console is initialized Could simply call Initialize wherever it needs to be called, but would rather be explicit. * Update AzDO build to use new 1ES pool * Add compliance build * Update targeting to Windows 7 * Enable ControlFlowGuard * Fix Prefast errors in source * Fix test prefast issues * Update to latest cached docker image * Suppress individual prefast warnings for fallthrough cases * FIxup comments for variants * Upgrade agent to Server 2019 with VS2019 (#260) Co-authored-by: Laurel Williams <20650063+lwillia@users.noreply.github.com> Co-authored-by: Davi Paulino <dalimapa@microsoft.com> Co-authored-by: Davi Paulino <davilimap@gmail.com> Co-authored-by: Tyler Dunkel <40210514+tydunkel@users.noreply.github.com>
Print instances to the terminal using colors from Visual Studio Code's Dark+ theme suitable for dark-themed terminals (common). A
-nocolorswitch is added in case it's necessary, but piping stdout to other programs or even using PowerShell accelerators like[xml]should work without-nocolorsince vswhere is not printing directly to the terminal.