Repository navigation
Make Clear-Host clear the scrollback buffer too on all platforms #8606
Description
Update:
The decision in #8603 to rely on Console.Clear() amounts to inconsistent behavior across platforms, for no good reason (there's no native behavior that needs to be emulated; native behavior, if desired, is accessible via the external clear utility).
If there's consensus that the desired behavior is to consistently clear the screen and the scrollback buffer on all platforms, we have two options:
-
Wait for
Console.Clear()to be fixed, if ever - see https://github.com/dotnet/corefx/issues/34463 -
Roll our own solution in PowerShell [in the meantime].
The original proposal below was written under the assumption that platform-dependent behavior was intended, and therefore suggested an opt-in mechanism.
Summary of the new feature/enhancement
Implement a switch named -All to direct Clear-Host to clear not only the current screen of terminal (console) hosts but to clear the scrollback buffer (the output history) as well.
Clear-Host now uses [Console]::Clear() (see #8603), which results in platform-specific behavior:
- Unix-like platforms: clears the current screen (terminal-window content) only.
- Windows: clears the current screen and the scroll-back buffer.
That is, also clearing the scrollback buffer is invariably implied on Windows, whereas it is currently unavailable on Unix-like platforms.
Implementing -All would allow users to at least opt into a consistent cross-platform experience, e.g. via a user-defined function such as function clsa { Clear-Host -All }.
Note: As before, this means that in the Windows console you do not have the option to selectively clear the current screen only, without erasing the scrollback buffer.
Proposed technical implementation details (optional)
If -All is specified:
- on Windows: do nothing, because clearing the scrollback buffer is invariably performed anyway.
- on Unix-like platforms, execute
$host.ui.Write("`e[3J")after[Console]::Clear()to also clear the scrollback buffer.
Activity
SteveL-MSFT commentedon Jan 8, 2019
The work to do this should be pretty minimal and straight forward. Remove
Clear-Hostas a function and reimplement as a C# cmdlet.dhulwells commentedon Jan 8, 2019
Can I take this one?
SteveL-MSFT commentedon Jan 8, 2019
Dhul Wells (@dhulwells) consider it yours! If you have something basically working, you can always submit as a Work-In-Progress PR if you need help (just put
WIP:as prefix to PR title)BrucePay commentedon Jan 8, 2019
Steve Lee (@SteveL-MSFT) Michael Klement (@mklement0) Since
Clear-Hoston Windows already clears the scrollback buffer, this new switch-Allwould be a useless parameter on Windows resulting in either an error or it being silently ignored if used, neither of which seem undesirable.We can certainly implement this on Windows if desired, but I don't know that I've ever wanted it. YMMV.
James Truher (@JamesWTruher) Joey Aiello (@joeyaiello) IIRC, the thrust of what we discussed in the committee meeting is that PowerShell would call
Console.Clear()on all 'console' platforms and the CoreCLR team would implement the appropriate behaviour on each platform. If the CoreCLR isn't doing the right thing on a platform, then a bug should be opened in the CoreCLR repo. BUT(!) we do still need to go through the$Host.UI.RawUIAPIs in order to support 'non-console' platforms like remoting. In fact, if theRawUIAPIs were fully supported on non-Windows console hosts, this whole discussion might be moot.SteveL-MSFT commentedon Jan 8, 2019
Bruce Payette (@BrucePay) it could be argued (and I expect the corefx team to argue) that [Console]::Clear() has the correct behavior from their point of view today which is terminal specific. Personally, I prefer to have the scrollback buffer cleared as my typical use case is that I clear the screen so I can output a bunch of content and expect the buffer to only have the new content whereas retaining the buffer means I have to visually determine where the new content exists when I use my scroll wheel. Having
-Allbeing no-op on Windows doesn't seem bad to me.mklement0 commentedon Jan 9, 2019
Amen to that.
So, from that perspective the best user experience would be to consistently clear the scrollback buffer too, on all platforms, as originally suggested in #8554.
Your decision was to rely on
[Console]::Clear(), which, I would argue, shouldn't exhibit platform-specific behavior either (and perhaps should offer a parameter for opting into screen-only clearing).So, yes, a CoreFx issue should be opened, but if the consensus is that we want buffer clearing on all platforms, we can certainly make that happen now without having to wait for
[Console]::Clear()to be fixed.mklement0 commentedon Jan 9, 2019
I've opened a CoreFx issue: https://github.com/dotnet/corefx/issues/34463
[-]Add a switch to Clear-Host to opt into clearing not just the current screen but also the scrollback buffer[/-][+]Make Clear-Host clear the scrollback buffer too on all platforms [/+]SteveL-MSFT commentedon Jan 9, 2019
Michael Klement (@mklement0) I had to rollback the change from [Console]::Clear() back to $RawUI since [Console]::Clear() doesn't work remotely when there isn't a physical console (see #8609).
iSazonov commentedon Jan 10, 2019
From #8609 (comment)
SeeminglyScience commentedon Jan 10, 2019
Is there any reason why these changes wouldn't go into
ConsoleHostinstead ofClear-Host? The host can decide what to do with the currentSetBufferContentseven if it doesn't really support the API. For example, PSES will invokeConsole.Clearif the args look like it came fromClear-Hostbut will no-op if it's passed anything else.I realize that #8609 already changes back to using
$Hostfor Windows, but is the expectation that custom hosts should replaceClear-Hostfor non-Windows?19 remaining items
iSazonov commentedon Nov 14, 2023
Michael Klement (@mklement0) Console.Clear was fixed in .Net 8.0. Can we close the issue?
mklement0 commentedon Nov 14, 2023
Ilya (@iSazonov), as of .NET 8.0.0-rc.2.23479.6 (the version underlying PowerShell 7.4.0-rc.1), it is not fixed on macOS.
I'm unclear on whether the fix hasn't landed yet, or whether it isn't effective on macOS.
iSazonov commentedon Nov 14, 2023
Michael Klement (@mklement0) I added comment in dotnet/runtime#28355
mklement0 commentedon Nov 14, 2023
Thanks, Ilya (@iSazonov) - indeed, as you've also found, it has not been fixed on macOS.
microsoft-github-policy-service commentedon May 13, 2024
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.