-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
conpty uses default history buffer length #2558
Comments
FYI this also affects the buffer count (for child processes that attach to the console) - see https://discuss.python.org/t/interactive-command-history-in-session-started-with-subprocess-on-windows/3701 for more. Though the original complaint in that post is about conhost.exe, it also applies to Terminal, but does not have the workaround. |
Anyway to work around this? Commands churn of the short 50 item history and I end up having to dig them up again and again... |
As a temporary (per-session) workaround, you can use As a quasi-permanent workaround, if you set the commandline of your Command Prompt profile to As an absolutely permanent workaround, if you use a more civilized shell you will never again be constained by the limitations of CMD |
Note that doskey.exe cannot extend the number of history buffers from the default value of 4, which is far too small. In many cases, 8 or more process end up attached to the console session. For system console sessions (conhost.exe), I change the command-history settings in the "Defaults" dialog (the default settings in "HKCU\Console") to use 32 history buffers. But for some reason, console sessions (tabs) in Windows Terminal ignore the default settings in the registry. So changing it requires calling
Surely you know that high-level reads via |
I certainly do, and don’t call me Shirley That joke doesn’t work so well in text form. I staunchly believe that giving the console host ownership of the command history was a mistake the consequences of which we must forever endure. 😄 I do think this is worth fixing, but perhaps more holistically. Do you think that it would present a correctness or compatibility issue to simply offer infinite history with infinite buffers? Barring infinite buffers being compatible, we could likely collect data on buffers or entries aging out and adjust our defaults accordingly. |
Allowing infinite history buffers with infinite history should be fine on the client side. The Defaults/Properties dialog could be updated with two check boxes that enable the infinite values. If selected, which should be the default setting (also for a conpty session), the corresponding text field in the UI should be disabled. The registry settings "NumberOfHistoryBuffers" and "HistoryBufferSize" are
NT's console had to provide functionality equivalent to DOSKEY (MS-DOS 5.0 TSR service, 1991) for 16-bit DOS programs such as COMMAND.COM. I guess this could have been left as a private interface for NTVDM. But the designer(s) decided to provide it for Windows console applications as well, as a consistent user interface for simple CLI programs. It probably made sense back then to implement the CLI editor centrally in the subsystem server (csrss.exe), rather than on the client side in kernel32.dll -- for the sake of efficiency given the resource constraints of PCs in the early 1990s. |
I'm bumping into this issue when using
|
Python If Windows Terminal would minimally increase the current limit of Or, give the Windows Terminal user a way of configuring this setting, please. Here's a link to the effort underway right now to improve the |
Doesn't work for me: |
From #13515, re "Discard Old Duplicates"
I wonder how much of a breaking change it would be to have ConPTY load the HKCU/Console "defaults" for |
It is related to #16198. This explains why it works for |
I've just come back to this issue because I have the following in my Powershell profile (which, if I recall, I found in a post from @eryksun somewhere):
Is this still needed? I'm on Windows 11, and #16198 says it's not an issue on Windows 11, but I don't know if that's relevant. More significantly, I've been experimenting with nushell, and I'm not sure if I need to copy this snippet into my nu profile, for situations where I start Windows Terminal without ever running Powershell. And similarly, if I run (for example) Python in VS Code, where neither Windows Terminal nor Powershell are invoked, do I still need this workaround? Essentially, if the workaround is still needed, having a global place where it can be run and will then be active for all terminal sessions would be far better than having to find a way to call |
I need to call
That was about a bug in the implementation of
I don't think something like that has ever been implemented on Unix systems. It always depends on a shell executing something like "~/.profile" or "~/.bashrc". This command-history problem would be better addressed in the long term by releasing a system Readline library. Applications would use the system library to store their own command history across console sessions instead of relying on a history buffer in the console host. |
Description of the new feature/enhancement
Right now cmd.exe instances opened by Terminal do not seem to obey the command buffer size set on cmd.exe, nor does it offer a way to set this within Terminal. Currently cmd.exe instances opened within Terminal seems hard coded to the default of 50.
The text was updated successfully, but these errors were encountered: