'MODE CON LINES=100' kills command prompt #5698

Open
opened 2026-01-31 00:19:25 +00:00 by claunia · 2 comments
Owner

Originally created by @Luuk34 on GitHub (Dec 26, 2019).

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.535]
Windows Terminal version (if applicable): 0.7.3451.0

Steps to reproduce

Open command prompt ('CMD'), and type 'MODE CON LINES=100'

Expected behavior

The screen is cleared, and prompt is shown at upper left corner.

Actual behavior

No prompt is show (at least characters of prompt are invisible).
command_prompt

Originally created by @Luuk34 on GitHub (Dec 26, 2019). # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18363.535] Windows Terminal version (if applicable): 0.7.3451.0 ``` # Steps to reproduce Open command prompt ('CMD'), and type 'MODE CON LINES=100' # Expected behavior The screen is cleared, and prompt is shown at upper left corner. # Actual behavior No prompt is show (at least characters of prompt are invisible). ![command_prompt](https://user-images.githubusercontent.com/7850737/71471452-cd0b3a00-27cf-11ea-92c5-431c4d18fef6.gif)
claunia added the Issue-BugArea-ServerProduct-ConptyPriority-2 labels 2026-01-31 00:19:25 +00:00
Author
Owner

@DHowett-MSFT commented on GitHub (Dec 31, 2019):

This may have been fixed (incidentally) at the same time as #3907; somebody will need to validate.

@DHowett-MSFT commented on GitHub (Dec 31, 2019): This may have been fixed (incidentally) at the same time as #3907; somebody will need to validate.
Author
Owner

@zadjii-msft commented on GitHub (Jan 2, 2020):

@DHowett-MSFT unfortunately, that's not the case :/

I think this might have to do with the screen attributes somehow. This doesn't repro with my usual prompt, but if I set PROMPT=$p$g, then this always repros. Even set PROMPT=$e[31m$p$g$e[39m will cause this to go away, so there's something wonky with the attributes happening here.


EDIT: oh no it's worse than that.

It will sometimes repro with my usual prompt. And sometimes it doesn't.

OH NO

I bet it actually does resize the conpty buffer. If you do this in inception (wsl.exe cmd.exe), the console will get bigger. But the Terminal doesn't act on that resize for whatever reason. Either the terminal isn't acting on the ^[[8<rows>;<cols>t sequence, or the resize is never being emitted by conpty. Probably running into that same if clause where we check the maximum possible size of the window, but we don't do that in conpty mode.

@zadjii-msft commented on GitHub (Jan 2, 2020): @DHowett-MSFT unfortunately, that's not the case :/ I think this might have to do with the screen attributes somehow. This doesn't repro with my usual prompt, but if I `set PROMPT=$p$g`, then this always repros. Even `set PROMPT=$e[31m$p$g$e[39m` will cause this to go away, so there's something wonky with the attributes happening here. <hr> EDIT: oh no it's worse than that. It will _sometimes_ repro with my usual prompt. And sometimes it doesn't. OH NO I bet it actually does resize the conpty buffer. If you do this in inception (wsl.exe cmd.exe), the console will get bigger. But the Terminal doesn't act on that resize for whatever reason. Either the terminal isn't acting on the `^[[8<rows>;<cols>t` sequence, or the resize is never being emitted by conpty. Probably running into that same `if` clause where we check the maximum possible size of the window, but we don't do that in conpty mode.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#5698