System.Console work planned for .NET 7

[jeffhandley]

This issue captures the planned work for .NET 7. This list is expected to change throughout the release cycle according to ongoing planning and discussions, with possible additions and subtractions to the scope.

Summary

During .NET 7, we will address some common pain points enable new functionality that improves the cross-platform experiences for .NET Console applications. We will contribute to the reconsideration of the new console template that was introduced in .NET 6. The discussion about a potential Console redesign will continue.

Planned for .NET 7

• Should the console project template use top-level statements docs#27420
• Console.ReadLine on Ubuntu in WSL disables echo of characters when cancelled with Ctrl-C #64166
• Console.ReadKey returns incomplete information for some key sequences on Linux #802
• Console.ReadKey behaves differently in .NET 6 comparing to .NET 5 when TERM is set to rxvt #63387
• Console.ReadKey and pressing SHIFT+END returns invalid escape sequence on WSL/Ubuntu #45597
• Console.OutputEncoding by default returns a wrong value on Windows Nano Server #42959
• .NET 5 fails to read the HOME key on ubuntu16.04 #44621
• Console.ReadKey returns incomplete VT sequences for bracketed paste #60101

Backlog (roughly in priority order)

• Console.ReadKey throws in unexpected circumstances #59059
• Developers using Console can employ VT/ANSI APIs (eg to use embedded color codes) #44513
• Enhance Console.ReadLine() to return at Tab #800
• Console.WriteLine() is not thread-safe #53751
• Terminfo direct color mode does not work #63645
• Console issues with multithreaded c# app only when run on Linux #49301
• Let System.ConsoleKeyInfo able to represent keypress in the Unicode world #51085
• Third party code may remove cancel keypress handler #30464
• Setting Console.TreatControlCAsInput to true causes text to be removable #44667
• Cannot use left/right arrow keys to edit text in Console.ReadLine on Unix #38051
• [API Proposal]: Allow Console.ReadKey to parse VT sequences when ENABLE_VIRTUAL_TERMINAL_INPUT is set on Windows #60107
• Console UTF-8 input is misbehaving on Windows #43295
• CancelKeyPressTests.HandlerInvokedForSigQuit test failing on OSX in CI #38998

Notable Discussions

• [Discussion] System.Console re-design #52374

[ghost]

Tagging subscribers to this area: @dotnet/area-system-console
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This issue captures the planned work for .NET 7. This list is expected to change throughout the release cycle according to ongoing planning and discussions, with possible additions and subtractions to the scope.

Summary

During .NET 7, we will address some common pain points enable new functionality that improves the cross-platform experiences for .NET Console applications. We will contribute to the reconsideration of the new console template that was introduced in .NET 6. The discussion about a potential Console redesign will continue.

Planned for .NET 7

Functionality

• Developers using Console can employ VT/ANSI APIs (eg to use embedded color codes) #44513
• Console.ReadKey returns incomplete information for some key sequences on Linux #802
• Enhance Console.ReadLine() to return at Tab #800
• Console.WriteLine() is not thread-safe #53751
• Console.ReadKey behaves differently in .NET 6 comparing to .NET 5 when TERM is set to rxvt #63387
• Terminfo direct color mode does not work #63645
• Console issues with multithreaded c# app only when run on Linux #49301
• Let System.ConsoleKeyInfo able to represent keypress in the Unicode world #51085
• Third party code may remove cancel keypress handler #30464
• Console.OutputEncoding by default returns a wrong value on Windows Nano Server #42959
• .NET 5 fails to read the HOME key on ubuntu16.04 #44621
• Setting Console.TreatControlCAsInput to true causes text to be removable #44667
• Console.ReadKey and pressing SHIFT+END returns invalid escape sequence on WSL/Ubuntu #45597
• Cannot use left/right arrow keys to edit text in Console.ReadLine on Unix #38051
• Console.ReadKey throws in unexpected circumstances #59059
• Console.ReadKey returns incomplete VT sequences for bracketed paste #60101
• [API Proposal]: Allow Console.ReadKey to parse VT sequences when ENABLE_VIRTUAL_TERMINAL_INPUT is set on Windows #60107
• Console UTF-8 input is misbehaving on Windows #43295
• Console.ReadLine on Ubuntu in WSL disables echo of characters when cancelled with Ctrl-C #64166

Tests

• CancelKeyPressTests.HandlerInvokedForSigQuit test failing on OSX in CI #38998

Project Template

• Should the console project template use top-level statements docs#27420

Console Redesign

• [Discussion] System.Console re-design #52374

Author:	jeffhandley
Assignees:	jeffhandley, adamsitnik, Jozkee
Labels:	Epic, area-System.Console, Priority:2
Milestone:	7.0.0

[davidfowl]

What about async console APIs on (workable on linux) cc @stephentoub ?

[jeffhandley]

This list in this issue has been edited to reflect changes from our ongoing planning and discussions. The headings have been updated to reflect what is still planned for .NET 7 and what is in the backlog. The list is still expected to change throughout the release cycle with periodic reviews of our plans.

@davidfowl / @stephentoub Can you share any more info on the async console APIs topic? Are there specific scenarios that you have in mind?

[stephentoub]

Can you share any more info on the async console APIs topic? Are there specific scenarios that you have in mind?

I don't know exactly what David was referring to in his comment, but broadly there are three areas here:

1. Make the asynchronous operations on the default Stream underlying Console actually asynchronous. Today they just inherit the base Stream behavior of doing async-over-sync (queuing a work item to invoke the corresponding sync methods). This isn't feasible on Windows today, but we could make it work on Unix, e.g. by leveraging the async infrastructure under Socket and having UnixConsoleStream use Socket to intact with the underlying file descriptor (in the future hopefully that infrastructure would move lower in the stack, but for now this should work, similar to what we do in PipeStream on Unix). If we did that, then the asynchronous operations on Console.Out and Console.In would be truly asynchronous. This is primarily useful when stdin/out/err have been redirected and Console is being used to read/write with a parent process.
2. Add async equivalents to methods like Console.Write, WriteLine, etc. This would be trivial once (1) was done, but they'd similarly be truly asynchronous on Unix only.
3. Add async equivalents to other methods like ReadKey, ones that actually interact with the terminal.

I'd like to see (1) done in .NET 7 if possible. There's no new API required, it's just making something existing work better.

I don't have strong feelings about (2), but I never love the idea of exposing new async APIs we couldn't actually make async everywhere. We'd also need to figure out the synchronization story around concurrent usage... today all the sync methods coordinate with a big lock around every operation.

And for (3), it's not something to tackle in 7. I don't even know if it's fully possible.

[davidfowl]

I was referring to 1 and 2, I remember we attempted that and then reverted in 6.0.