Closed ivdiazsa closed 4 months ago
Looks like we're just checking if TERM
isn't dumb
- Spectre.Console has a series of expected TERM values that they use for probing - should we use that to align more?
Looks like we're just checking if
TERM
isn'tdumb
- Spectre.Console has a series of expected TERM values that they use for probing - should we use that to align more?
Interesting, you do have eterm
listed there. I wonder if eterm-color
is treated as a completely different one.
Adding for more information:
echo $TERM
eterm-color
Looks like we're just checking if
TERM
isn'tdumb
- Spectre.Console has a series of expected TERM values that they use for probing - should we use that to align more?Interesting, you do have
eterm
listed there. I wonder ifeterm-color
is treated as a completely different one.Adding for more information:
echo $TERM eterm-color
Yes, eterm is listed there and actually "eterm-color" is an acceptable terminal type because of that. Which is probably not quite correct detection: this type only recognizes the ANSI codes that control coloring, and not the ones that moves cursor, for example (checked it in the Emacs Terminal). And it seems to me that both our projects need moves of the cursor.
Overall, I think we need to improve our detection. I see two ways: either we do what Spectre.Console does and have a list of allowed terminal types for the Terminal Logger. Or we obtain the information via parsing the capabilities of a terminal using the terminfo
database and comparing them to whatever capabilities we need for Terminal Logger to work. It might be quite tricky to do so though. I found that runtime does something similar.
Issue Description
The newest version of .NET 9 implements a new console logger, which displays build status in a more "real-time" format by overwriting the progress line. This looks great, however, it does not work properly in some specific terminals, like for example the Emacs Terminal (not Emacs Shell).
Steps to Reproduce
In the terminals that don't like the new logger, building any dotnet app reproduces the issue. I'm using this command for mine:
dotnet build -c Release -o out
It is worth mentioning that we can get around this issue by passing the flag
-tl:false
to the dotnet command.Expected Behavior
Displays only one line of progress in a clean format:
Actual Behavior
In said terminals, the carriage return seems to be getting messed up and the output looks like this:
Analysis
No response
Versions & Configurations
This is my dotnet installation (output of
dotnet --info
):