Strings with Virtual Terminal (VT) / ANSI escape sequences that are truncated for display make effects linger

[mklement0]

^{Related: #7744}

Virtual Terminal escape sequences allow, among other things, formatting of console (terminal) output, notably to produce colored output.

An escape sequence that changes the output color - e.g., "`e[32m" to switch to green - stays in effect until the color is reset - e.g., with "`e[m"

Example:

"before `e[32mgreen`e[m after"  # prints only the word "green" in green.

Therefore, if PowerShell truncates strings for output formatting, a string may get cut off so that the reset sequence is not output, which means that the color unexpectedly stays in effect.

#7744 shows the problem in the context of using an OSC escape sequence to construct a hyperlink (which only some terminals support; others render just the link label).

This is a nontrivial problem to solve, because PowerShell would have to be aware of all potential escape sequences and know how to reset their effects so that the appropriate escape sequence can be appended to the truncated string.

Steps to reproduce

[pscustomobject] @{ test1="before `e[32mgreen`e[m after"; test2='next col' } | Format-Table @{ e='test1'; width=17 }, test2

Expected behavior

test1              test2
-----              -----
before gr...       next col

gr... should render green, but next col should render with the default color.

Actual behavior

test1             test2
-----             -----
before gr...  next col

That is, next col too is printed in green, and green output stays in effect (the prompt rendered after the command will be green too).

Additionally, note that the column alignment is off.

Environment data

PowerShell Core v6.1.0-rc.1 on macOS 10.13.6
PowerShell Core v6.1.0-rc.1 on Ubuntu 16.04.4 LTS
PowerShell Core v6.1.0-rc.1 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)

[iSazonov]

I would like to know that there is a better practice for working with VT.

[mklement0]

What do you mean by that, @iSazonov?

[SteveL-MSFT]

It seems we could go with a simple approach and always reset the console color anytime after we truncate.

[mklement0]

That's promising, @SteveL-MSFT; it will definitely work with colors, but is there an equivalent generic reset mechanism for other types of escape sequences, such as the OSC sequences mentioned in #7744? (There may be, I haven't checked).

"`e[m", which works for colors, does not work for OSCs.

[iSazonov]

We don't want to see escapes in trace log. So we need a rendering subsystem.

[SeeminglyScience]

Worth noting that `e[m won't reset underline (at least on Windows), so `e[24m may be needed as well.

[mklement0]

That smells like a bug, @SeeminglyScience, and I actually can't reproduce it on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.285)

Does the following really not work for you?

"before `e[4munderlined`e[m after"

[SeeminglyScience]

@mklement0 huh, it does now. I wonder if a Windows update fixed that or if I'm just thinking of something else...

Either way nevermind :)

[jazzdelightsme]

I made the same comment on #7744, but: DbgShell's approach is not to try to reset/undo escape sequences; rather just leave them all in. In other words, when truncating, it only truncates content, but preserves all escape sequences (code here).

That said, resetting does seem like a good idea in general for a formatting engine. I came searching for Issues after running Get-Variable where I had a bunch of variables like ${RED}, ${YELLOW}, ${BLACK}, etc. defined, which totally horked my console. Fortunately I also had a Reset-Colors command.