PowerShell
PowerShell copied to clipboard
`Write-Host`'s `--*groundColor` doesn't work when inside an instance piped to another command
Prerequisites
- [X] Write a descriptive title.
- [X] Make sure you are able to repro it on the latest released version
- [X] Search the existing issues.
- [X] Refer to the FAQ.
- [X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
From outside powershell, run a powershell script that produces colours using Write-Host --ForegroundColor, and then pipe that output for further processing.
In the attached image I show
- coloured text can be pushed through
Write-Host, even if the output is processed - coloured text can be generated by
Write-Host --*groundColor, if not post-processed - coloured text cannot make it out from
Write-Host --*groundColor, if post-processed - same as test 1, but manual
Expected behavior
Colours are maintained.
Actual behavior
Colours are not maintained.
Error details
No response
Environment data
PSVersion 7.3.4
PSEdition Core
GitCommitId 7.3.4
OS Linux 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21)
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Visuals
It works inside pwsh-session:
PS. I think bash can't interpret grave character correctly as it's service one.
@Hashbrown777, I suggest closing this in favor of:
- #20171
As for your commands:
What it comes down to is that Write-Host output on stringification invariably loses its color if the color is produced via -ForegroundColor / -BackgroundColor (as opposed to explicit ANSI/VT sequences being part of its argument(s)) - which it shouldn't.
Stringification happens when the CLI's stdout stream isn't connected to a terminal.
Hm, my only issue with that is that that is written like a feature request whereas this is a bug. That request being fulfilled would be the way to solve this problem though.
~~However, I think it should produce the colour~~(edit; misread I think). Unlike other things that automatically disable colours (like ls itself) when not attached directly to a tty, we're explicitly telling Write-Host "-BackgroundColor" (just like with ls' --color).
I'll leave it to the triaging dev to decide, but I'd think they might make 20171 a dupe, instead if there's more traction there then that'll get done and this'll get closed naturally.
As for automatically disabling colors when not attached to a tty in CLI use, see:
- #20170
Given the $PSStyle.OutputRendering mechanism, I feel that it should apply even to explicit use of -ForegroundColor / -BackgroundColor with Write-Host; $PSStyle.OutputRendering is PowerShell's command-independent equivalent of the per-utility --color=auto|always|never parameter of GNU utilities.
The reason that #20171 was submitted as a feature request rather than as a bug report is that, Write-Host -ForegroundColor / -BackgroundColor predates PowerShell's ANSI/VT sequence support and never promised to produce the latter when captured.
I think that the introduction of VT sequences was a far-reaching change, and the behaviour described here is an oversight when implementing that; buggy. Nothing's gained from us closing it, I'll leave it to them.
Makes sense. Given #20170, let me modify your third command as follows, to avoid ambiguity:
# With unconditional output of ANSI/VT sequences, *redirected* stdout should see them too.
pwsh -Command '$PSStyle.OutputRendering = "Ansi"; Write-Host test -ForegroundColor Blue' | cat