Progress indicator broken on Alacritty with ConPTY

[LPGhatguy]

Problem

When updating a toolchain, Rustup tries to draw over its previous progress indicators, but fails, and instead produces beautiful art:

Steps

1. rustup update stable, or another command that causes Rustup to output progress

Possible Solution(s)

Bash in Alacritty in Windows is a pretty weird config. 😄

Notes

Windows 10, Build 1809.

Alacritty has enable_experimental_conpty_backend set, which uses the Windows ConPTY API (1809+ only) instead of WinPTY, which is pretty buggy.

$ alacritty --version
alacritty 0.3.2
$ rustup --version
rustup 1.18.1 :: 1.18.0+20 (462683b3a 2019-04-25) dirty 1 modification

[rbtcollins]

So this is interesting; it looks like we're either not sending a \r correctly, or the number of spaces being sent to overwrite content is wrong, leading to wrapping to the next line, and so on. Probably some diagnostic testing will be needed to determine what terminfo we're ending up with with term today.

[rbtcollins]

Capturing from discord: TERM= rustup toolchain add nightly displays correctly but without colour. TERM=xterm-256color otherwise.

The term package fallsback to probing the Windows Console via console APIs when TERM is unset, and if that fails, rustup then creates a Terminal object that tries to work with dumb terminals (e.g. just depends on \r and discards attempts to do bold/colour etc).

So there are two possible code paths we're encountering here when you set TERM=

• Windows console detected by term.
• Rustup no-terminfo-fallback.

So this raises several aspects: -> either we have some weird bug, or alacritty isn't actually xterm-256color compatible. -> we may have a conpty detection bug ->or we may have a bug doing colour on a detected windows console with conpty

For the latter two need to know which of the code paths we're following; for the former, that seems most likely to be an alacritty issue. I'm not sure how to tell which we've encountered from a binary; I suggest building a rustup with some debug code (insert into fn make_terminal<T>(terminfo: Option<TermInfo>) -> Option<Box<Terminal<Output = T> + Send>> in term2.rs). - that should let you determine which path is being followed.

If the Windows console path is being detected, I would have expected colour to work; so I suspect that its not being detected, and you are ending up with the no-terminfo-fallback.

[kinnison]

This kind of failure mode is something we attempted to fix with the downgrade of term to before the fallback terminfo thing. I wonder what we could do to output some useful debugging of what kind of terminal object we've ended up with?

[davidhewitt]

I just discovered that this issue is not unique to Alacritty: if TERM is set in Windows Terminal then the output is broken in the same way as with Alacritty.

This might turn out to be an issue in all ConPTY-backed terminal emulators when TERM is set to xterm-256color?

[kinnison]

It's quite probable that this is true yes. ConPTY is not really an ANSI/VTxxx terminal which is part of the reason to want to shift to a more modern windows-aware library.

[davidhewitt]

I get the impression from discussion on microsoft/terminal that they're working very hard to support VT (and considering the Windows console APIs mostly for legacy programs).

If we can identify a VT sequence we're emitting which Windows is handling incorrectly and report it as a bug upstream, I'm fairly sure they'll fix it.

[kinnison]

So a lot of the issue is that terminal IO crates which expect to be able to deal in VT like commands tend to expect terminfo databases to be available at well known POSIX paths. They tend to assume therefore that if they're on Windows, the only thing they should do is ConPTY. What we need is to move to a terminal crate which does a better job of that, such as indicatif and we have an issue open to think about that, but little to no time has been invested yet in working out what it'd take to do.

[workingjubilee]

@rustbot label: +O-windows

[kirawi]

I've got something working, hopefully I'll be able to submit a PR later today.

[ryanavella]

I'm seeing the same thing on FreeBSD whether TERM is xterm or xterm-256color, so maybe this isn't purely a ConPTY thing?

[rami3l]

@kirawi @ryanavella Sorry for the long wait, but I am happy to inform you that @FranciscoTGouveia has come up with a new indicatif migration attempt in https://github.com/rust-lang/rustup/pull/4426.

Since this new implementation has deviated a bit from the original ones in terms of the approach being taken, would you mind verifying if that patch can solve your issue here as well? Many thanks in advance!