Repository navigation
Progress indicator broken on Alacritty with ConPTY #1826
Description
Problem
When updating a toolchain, Rustup tries to draw over its previous progress indicators, but fails, and instead produces beautiful art:
Steps
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
Activity
rbtcollins commentedon May 5, 2019
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 commentedon May 5, 2019
Capturing from discord:
TERM= rustup toolchain add nightlydisplays correctly but without colour. TERM=xterm-256color otherwise.The
termpackage 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\rand discards attempts to do bold/colour etc).So there are two possible code paths we're encountering here when you set
TERM=term.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 commentedon May 7, 2019
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 commentedon Dec 9, 2019
I just discovered that this issue is not unique to Alacritty: if
TERMis 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
TERMis set toxterm-256color?kinnison commentedon Dec 10, 2019
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 commentedon Dec 10, 2019
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 commentedon Dec 13, 2019
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
indicatifand 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 commentedon Apr 29, 2021
@rustbot label: +O-windows
kirawi commentedon Jul 16, 2021
I've got something working, hopefully I'll be able to submit a PR later today.
ryanavella commentedon Mar 29, 2023
I'm seeing the same thing on FreeBSD whether
TERMisxtermorxterm-256color, so maybe this isn't purely a ConPTY thing?rami3l commentedon Jul 27, 2025
@kirawi @ryanavella Sorry for the long wait, but I am happy to inform you that @FranciscoTGouveia has come up with a new
indicatifmigration attempt in #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!
rami3l commentedon Sep 3, 2026
As there are currently no further actions that can be taken from our side with respect to this issue since the migration to
indicatifin #4426, I'm closing it now as stale.Please feel free to reopen this issue if you have more information to provide.
Have a nice day :)