CUU and CUD commands should be constrained by the scrolling margins #246

Closed
opened 2026-01-30 21:46:44 +00:00 by claunia · 2 comments
Owner

Originally created by @j4james on GitHub (May 5, 2018).

  • Your Windows build number:

Microsoft Windows [Version 10.0.16299.371]

  • What you're doing and what's happening:

I'm setting the top and bottom scrolling margins with the DECSTBM escape sequence, then using the CUU and CUD sequences to move about within that range. According to the VT100 documentation for CUU: "If an attempt is made to move the cursor above the top margin, the cursor stops at the top margin." Similarly for the CUD command: "If an attempt is made to move the cursor below the bottom margin, the cursor stops at the bottom margin.

But that's not the behaviour I'm seeing in the Windows console. In the test case below, I've set the top margin to 8, the bottom margin to 16. Then starting from the centre of that range, I move down 99 lines and output some text to mark the bottom of the range, then up 99 lines to mark the top of the range.

printf "\ec\e[8;16r\e[12H\e[99BBOTTOM\r\e[99ATOP\n"

If everything is working correctly, I'd expect the TOP and BOTTOM markers to be on line 8 and 16 respectively, but in the Windows console they appear at the very top and bottom of the screen. The screenshots below compares the output on XTerm, Konsole, Gnome Terminal, and the Windows console (left to right).

image

  • What's wrong / what should be happening instead:

The vertical cursor movement commands CUU and CUD should not be able to move outside the scrolling margins - they should be constrained within those boundaries, the same way the various Linux terminal emulators behave.

Originally created by @j4james on GitHub (May 5, 2018). * Your Windows build number: Microsoft Windows [Version 10.0.16299.371] * What you're doing and what's happening: I'm setting the top and bottom scrolling margins with the DECSTBM escape sequence, then using the CUU and CUD sequences to move about within that range. According to the VT100 documentation for CUU: "If an attempt is made to move the cursor above the top margin, the cursor stops at the top margin." Similarly for the CUD command: "If an attempt is made to move the cursor below the bottom margin, the cursor stops at the bottom margin. But that's not the behaviour I'm seeing in the Windows console. In the test case below, I've set the top margin to 8, the bottom margin to 16. Then starting from the centre of that range, I move down 99 lines and output some text to mark the bottom of the range, then up 99 lines to mark the top of the range. printf "\ec\e[8;16r\e[12H\e[99BBOTTOM\r\e[99ATOP\n" If everything is working correctly, I'd expect the TOP and BOTTOM markers to be on line 8 and 16 respectively, but in the Windows console they appear at the very top and bottom of the screen. The screenshots below compares the output on XTerm, Konsole, Gnome Terminal, and the Windows console (left to right). ![image](https://user-images.githubusercontent.com/4181424/39664816-6de5bf5e-5081-11e8-98c0-39176a115354.png) * What's wrong / what should be happening instead: The vertical cursor movement commands CUU and CUD should not be able to move outside the scrolling margins - they should be constrained within those boundaries, the same way the various Linux terminal emulators behave.
claunia added the Product-ConhostResolution-Fix-Available labels 2026-01-30 21:46:44 +00:00
Author
Owner

@j4james commented on GitHub (May 5, 2018):

I should probably also mention that the VT52 movement commands (ESC A and ESC B) have the same problem. They're a little more difficult to test, since you can only move one line at a time, but the script below demonstrates the issue in a similar way.

#! /usr/bin/env bash
printf "\ec\e[8;16r\e[12H\e[?2l"
for i in {1..99}; do printf "\eB"; done
printf "BOTTOM\r"
for i in {1..99}; do printf "\eA"; done
printf "TOP\n\e<"

Note the \e[?2l sequence is necessary to enable VT52 mode on most terminals, and the \e< sequence is to switch back to VT100 mode.

The results are much the same as before, except that Gnome Terminal doesn't support the VT52 commands at all.

@j4james commented on GitHub (May 5, 2018): I should probably also mention that the VT52 movement commands (`ESC A` and `ESC B`) have the same problem. They're a little more difficult to test, since you can only move one line at a time, but the script below demonstrates the issue in a similar way. #! /usr/bin/env bash printf "\ec\e[8;16r\e[12H\e[?2l" for i in {1..99}; do printf "\eB"; done printf "BOTTOM\r" for i in {1..99}; do printf "\eA"; done printf "TOP\n\e<" Note the `\e[?2l` sequence is necessary to enable VT52 mode on most terminals, and the `\e<` sequence is to switch back to VT100 mode. The results are much the same as before, except that Gnome Terminal doesn't support the VT52 commands at all.
Author
Owner

@zadjii-msft commented on GitHub (Oct 25, 2018):

Looks like it's fixed in the 2018 October Update.

@zadjii-msft commented on GitHub (Oct 25, 2018): Looks like it's fixed in the 2018 October Update.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#246